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

本連載は、「Microsoft SQL Server」で発生するトラブルを「どんな方法で」「どのように」解決していくか、正しい対処のためのノウハウを紹介します。今回は「データベース刷新でアプリケーションのレスポンスが悪くなった事例とその対処方法」を解説します。

[内ヶ島暢之，ユニアデックス株式会社]

連載バックナンバー

　本連載では、「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　パフォーマンスカウンターで「ページング」の状況を確認

目次に戻る