NANAシステム開発 株式会社
STAFF BLOG

SQL Server のログに「パフォーマンスが低下する可能性があります」と出た話

2026.03.23

 

こんにちは。NANAシステム開発SYです。今回は技術ネタです。

ある日、DB サーバのイベントログを眺めていたところ、

「SQL Server のメモリがページアウトされ、パフォーマンスが低下する可能性があります」

という、なかなか不穏な警告が出ているのに気づきました。該当するログはこれです。


イベント ID 17890(ソース:MSSQLSERVER)

SQL Server プロセス メモリの重要な部分がページ アウトされました。

これにより、パフォーマンスが低下する可能性があります。


文面だけ読むと、

  • メモリが枯渇している?
  • 実はもう遅くなっている?
  • 何か設定を変えないとまずい?

と、つい身構えてしまいがちですが、、、

こういうログこそ一旦落ち着いて事実を整理するのが大事だと思います。

 

イベント ID 17890 とは何か

 

まず、このイベント ID 17890 ですが、SQL Server が「自分のプロセスに割り当てられているメモリのうち、物理メモリとして保持されている割合がかなり低い状態だな」と判断したときに出す警告ログです。ポイントは、Warning(警告)であってエラーではない今すぐ障害、という意味ではないというところ。
要は、「この状態が続くと、パフォーマンスに影響する可能性があるよ」という、いわば事前注意的なログってことです。

 

ログに出てくる各数値の意味

 

このイベントには、だいたい以下の数値がセットで出力されます。今回のログでは、こうなっていました。

Duration(秒):603
Working set (KB):339,944(約 340MB)
Committed (KB):783,632(約 780MB)
Memory utilization (%):43

これだけだと、何事か分からないので、それぞれ順に説明していきますね。


■ Duration(秒数)

 

ページアウト状態がどれくらいの時間続いているか を示します。

0 秒 → 検出直後
数百秒 → 「しばらくこの状態」

今回は 603 秒なので、一瞬ではなく、ある程度継続していたことが分かります。

 

■ Working set(作業セット)

 

SQL Server プロセスが、実際に物理メモリ(RAM)上に置いてもらえている量です。OS が「ちょっとメモリ空けたいな」と判断すると、ここが削られ、ページアウトされていきます。

 

■ Committed(コミット済みメモリ)

 

SQL Server が「自分はこれだけメモリを確保している」と認識している総量です。これは、実メモリとページファイル(仮想メモリ)を合わせた概念になります。

 

■ Memory utilization(%)

 

「確保しているメモリのうち、何%が物理メモリに載っているか」を見るための指標です。次の計算結果が表示されています。

Working set ÷ Committed × 100


 

では、上記の理解を元に今回の数値が示していることを整理していきます。

 

確保しているメモリ:約 780MB

実際に物理上にあるメモリ:約 340MB

つまり、物理メモリ上にあるのは約 43% という状態です。

 

SQL Server は、この状態を見て、「確保してるメモリの半分以上がページアウトされちゃってるな」と判断し、イベント ID 17890 を出した、という流れになります。

一般的にこの警告は、Working set ÷ Committed の比率が 50% を大きく下回る状態が一定時間続いた場合に出やすいと言われています。

※ なお、これはMicrosoftの公式サイトによると、公開された厳密な仕様値というより、SQL Server 内部の判断ロジックによるものです。実務的には「50% が一つの目安」と考えて問題ないと思います。

 

今回は問題になるのか?

 

ここが一番気になるところですが、結論から言うと 今回は特に問題になるケースではなさそうです。というのも、以下の要因が判っていたからです。

・ログが出ている時間帯で、大きなクエリやバッチが動いていない

・SQL Server は低負荷時に大量の物理メモリを保持し続ける必要がない

・OS 側の都合で一時的にページアウトされるのは普通に起きる

 

そもそもなんですが、SQL Server は、

1.まず物理メモリを使う

2.足りなければページングに回る

という性質を持っています。そのため、今後負荷が上がれば、

 

1.物理メモリが再び割り当てられる

2.Working set が増える

3.Memory utilization が回復して、この警告も自然に出なくなる

 

という動きになる可能性が高いと考えます。

 

設定変更で消すべきか?

 

ちなみに、「この警告が出るのが嫌だから何か設定を変えたい」という話であれば、
min server memory を 0 ではなく、ある程度大きな値(例えば 10GB など)にする、という選択肢はあります。

ただしこれは、実際に性能問題が起きているわけではないのに、単にログを見えなくするだけの目的で行うため、OS 側のメモリ余裕を減らすリスクもあります。

そういった点を考えると、あまり意味のある対処とは言えないかな、という印象です。

 

結論

 

まとめると、

・イベント ID 17890 は即障害を示すものではないことが判った。

・今回の数値で警告が出た理由は、仕組み的に妥当だった。

・低負荷時に一時的に出る分には特に問題ないと考えてもいいと思う。

・実際の性能劣化がなければ、基本は放置で OKと思う。

という事なので、

今回は「仕組みとして理解しておけば十分な警告」

という結論に落ち着きました。

 

今後もし、

・高負荷時にも頻繁に出る

・体感できる遅延とセットで起きる

・OS 全体のメモリ逼迫が見える

といった状況になったら、その時は改めて深掘りすれば良いかなと考えています。

皆様のお役に立てれば幸いです。