データベース処理が「特定のタイミング」でのみ遅くなる（パフォーマンストラブル）：SQL Serverトラブルシューティング（48）（1/2 ページ）

本連載は、「Microsoft SQL Server」で発生するトラブルを「どんな方法で」「どのように」解決していくか、正しい対処のためのノウハウを紹介します。今回は「処理が“特定のタイミング”でのみ遅くなってしまう事例とその対処方法」を解説します。

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

連載バックナンバー

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

トラブル 35（カテゴリー：処理遅延）：処理が「特定のタイミング」でのみ遅くなる

目次

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

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

トラブルの実例：平日と休日でシステムが分離されている基幹システムを運用中。この環境では、平日最終日の夜中に平日系システムを停止し、休日系システムの起動と業務開始処理が実行される。併せて、休日最終日の夜中に休日系から平日系への切り替えが同様に行われる。

　ある日、平日系システムで業務を開始した際に、平日系システムの稼働開始直後に実行されるバッチプログラムの処理が当初の想定よりも格段に遅いことが判明した。このバッチは毎日定時に実行されるものだが、休日系システムから平日系システムへ切り替えた日「のみ」で遅延が発生する。

　ひとまず「対象のバッチ処理が終了するまで他の処理を実行しない」とする方針で回避しようとしたが、目覚ましい改善はなかった。

トラブルの原因を探る

　この環境のシステム概要図は以下の通りです（図1）。

図1　今回の例のシステム概要図

　やはり場当たり的な対処ではなく、「なぜ休日系から切り替えた日だけ発生するのか」の原因を追究することが必要となります。

　まず、発生条件の切り分けとサーバリソース（CPUやメモリ、ディスクI/O）を調査します。以下のことが分かりました。

• CPUリソース：十分な余裕があり、問題はない（○）
• メモリリソース：上限値を設定しており、物理メモリの空きもある。Page Life Expectancyなどの指標でもメモリ不足を示していない（○）
• ディスクリソース：遅延発生時間帯は、読み込み量のI/Oが他の曜日よりも多かった（×）

　ディスクI/Oに問題がありそうです。なぜI/Oが多いのかを追究するためにアプリケーションチームと共同で調査したところ、該当するバッチプログラムは「比較的大きなテーブルの“全データ”を必要としていること」が分かりました。ただし、このプログラムはどうしてもこのロジックを変えられないとのこと。インフラ側でなんとかチューニングできないかを検討することにします。

　まだ疑問は解消できていません。なぜ「同じ処理なのに、なぜ休日明けの日にだけ発生するのか」です。この発生条件の違いを比較すると、以下のことが分かりました。

• 休日系から平日系へ切り替わる日は、処理すべきデータ量が「他の平日より多い」
• 遅延発生時はディスクへのI/O量が特に多く、それが処理時間のほとんどを占めている

　ようやく特定の日だけI/O時間が長い理由も分かりました。

ワンポイント

　判明したことを「可視化」「リスト化」して、「保存する」「共有する」こともトラブルシューティングの基本です。トラブルシューシングは調査した結果をベースに仮説検証していく作業です。もしその仮説が間違っていたならばロジックを見直して再調査し、それを繰り返すことで原因を追究していきます。

　それには、何がファクトで、どの考察が誤っているのかを再度チェックする必要があります。そのために過去の調査結果や議論を忘れないように記録しておくことが肝心です。

目次に戻る