プライベートクラウド環境へ移行したら、アプリケーションのレスポンスが悪くなった（パフォーマンストラブル）：SQL Serverトラブルシューティング（44）（1/2 ページ）

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

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

連載バックナンバー

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

トラブル 31（カテゴリー：処理遅延）：プライベートクラウド環境へ移行したら、アプリケーションのレスポンスが悪くなった

目次

• トラブルの実例
• トラブルの原因
• 解決方法

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

トラブルの実例：自社内で大規模な投資を行い、プライベートクラウドを構築。そこにデータベースサーバを展開して運用を開始した。

　稼働は順調だったが、特定の周期で処理遅延が発生することが判明した。

目次に戻る

トラブルの原因を探る

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

• CPUリソースには十分な空きがある
• 物理メモリの空きは十分あり、Page Life Expectancyも「300」を大きく上回っている
• 通常時と異常時で、データベースへのI/Oの量は変わらない
• ただし、ディスクのカウンターを確認すると「Current Disk Queue Length」が増加していた

図31-1　データベースサーバのパフォーマンスログを確認。CPUリソースは余裕がある

図31-2　メモリの空き容量にも余裕がある

図31-3　Page Life Expectancyも「300」を大きく上回っている

図31-4　ただし、「Current Disk Queue Length」が増加していた

　「トラブル 30：老朽化したデータベースを刷新したのに、アプリケーションのレスポンスが悪くなった」の事例と違い、今回はメモリ不足が原因ではありません。しかし、「Current Disk Queue Length」を確認すると、9時30分以降でI/O待ちが急に増えていたことが分かりました。このことから、このトラブルの原因はディスクI/Oにあると推定されます。併せてディスク関連のカウンターをさらに確認すると「Disk Idle Time」が極端に低下していることも分かりました。Disk Idle Timeが極端に低いということは、Windowsから見るとディスクがビジー状態で、I/Oができないことを示しています。

　なぜディスク側で処理が止まっているのでしょう。それを調査するために、まず「接続されているディスクの調査」が必要です。今回のシステムはプライベートクラウド環境での例なので、仮想化基盤全体の調査を行うということになります。

　筆者が主に確認するディスク関連のカウンターは以下の通りです。これらの値を採取し、正常時と異常時とを比較します。「データベース処理遅延に対処するための『パフォーマンスログ』を採取する方法」で解説したパフォーマンスカウンターとともにこちらも追加しておくとよいでしょう。

オブジェクト名	カウンター名	内容
Physical Disk	Avg. Disk Queue Length Current Disk Queue Length	ディスクへのI/O待ちになっている要求の数
	Disk Reads/sec Disk Writes/sec	1秒当たりのI/O読み書き数
	Avg. Disk sec/Read Avg. Disk sec/Write	I/O当たりの平均処理時間
	%Idle Time	OSから見たディスクの活動状況

　この事例では、ディスク側で定期的なメンテナンスジョブが動いており、それが接続されている仮想マシンへのサービスよりも優先度が高く設定されていました。そのために、データベースのI/Oが影響を受けていました。

目次に戻る