老朽化したデータベースを刷新したのに、かえってアプリケーションのレスポンスが悪くなった（パフォーマンストラブル）：SQL Serverトラブルシューティング（43）（1/2 ページ）

連載バックナンバー

　本連載では、「Microsoft SQL Server（以下、SQL Server）」で発生するトラブルについて、「なぜ起こったか」の理由とともに具体的な対処方法を紹介していきます。

トラブル 30（カテゴリー：処理遅延）：老朽化したデータベースを刷新したのに、アプリケーションのレスポンスが悪くなった

　「Windows Server 2012 R2」上に「SQL Server 2016 RTM」をインストールした環境を想定して解説します。

トラブルの原因を探る

　データベースサーバの情報を調べたところ、以下ような状況でした。

• CPUリソースには十分な空きがある（図30-1）
• ただし、物理メモリの空きが20MBほどになっていた（図30-2）
• 併せて、データベースファイルを配置したドライブと起動ドライブのI/Oが多く、I/O待ちが発生していた（図30-3）

図30-1　データベースサーバのパフォーマンスログを確認。CPU利用率は平均で15％程度だった

図30-2　ただし、メモリの空き容量は20M〜30MBほどしかなかった

図30-3　併せて、ディスクのI/O待ちが多く発生していた

　なぜメモリ不足とI/O増加が発生していたのでしょう。SQL Serverの設定を再確認します。インスタンスのプロパティから「最大サーバーメモリー」の項目を確認すると、2147483647に設定してありました。メモリの最大容量は「実質無制限」、つまり「使えるだけ使う」という設定です。

　メモリのボトルネックも調べます。パフォーマンスカウンターで「Page Life Expectancy」の値を確認します（図30-4）。

図30-4　パフォーマンスカウンターで「Page Life Expectancy」の値を確認

　Page Life Expectancyは、ディスクから読み出したデータページがメモリ上でどのくらい滞留したのかを示す値です。この値が定常的に300秒を下回る状態だと、メモリのバッファーが少ない状態、つまり、SQL Serverがメモリ不足になっているとみなせます。図30-4から、明らかにしきい値である300秒を下回っている時間が長いことが分かりました。

　続いてディスクI/Oを調査します。パフォーマンス問題が起きている状況下で、なぜ起動ドライブ（Cドライブ）の負荷が増えているのかが気になります。WindowsにおけるCドライブは、一般的にはWindowsのOSカーネルやプログラムのバイナリが格納されていますが、通常、それらがデータベースやアプリケーションの深刻なパフォーマンストラブルにつながることはありません。今回疑うべきは「ページファイル」です。

　ページファイルは、Windowsが仮想メモリを実装する際に利用するメモリデータの待避領域として、ディスク上に作成されます。これはOSがプロセス（今回のケースで言うとSQL Server）へ仮想メモリ空間として割り当てるのですが、当然、他のプログラムやOSそのものも物理メモリを利用するので、仮想メモリ全てを物理メモリにロードするわけではありません。サーバの物理メモリが不足してくると、OSの正常動作として物理メモリにあるデータの一部をページファイルへ退避します。これを「ページング」と呼びます。

　あらためてページングのパフォーマンスカウンターを確認すると、明らかにページングの割合が増えていました（図30-5）。前述したように、ページングは物理メモリ不足によって発生します。つまり、CドライブへのI/O増はこの物理メモリ不足に起因していることが分かりました。

図30-5　パフォーマンスカウンターで「ページング」の状況を確認