この投稿では、CPUパフォーマンスの問題をトラブルシューティングするための一般的な方法について説明します。私はデフォルトで方法論を適用するのが好きで、過去の経験に基づいて問題をトラブルシューティングする方法を効率化するのも好きです。一般的な枠組みがなければ、危機の最中に真の根本原因を見逃しやすくなります。
この投稿で説明する手順は次のとおりです。
- 問題を定義する
- 現在の状態を検証する
- 「SQLServerですか？」と答えますか？
- CPUコンシューマーを特定する
- パターンを一致させて解決する
この記事では、これらの各ステップについて説明します。サードパーティの監視ツールを使用していない可能性があることを前提としています。ただし、ここでのフレームワークは引き続き適用されますが、自由に使用できるデータソースとツールは、私が説明したものとは異なります。
問題を定義する
まず、問題の範囲を特定する必要があります。誰かがあなたのところに来て、CPUパフォーマンスの問題が発生していると言った場合、これはさまざまなことを意味する可能性があります。したがって、最初のタスクは、CPUパフォーマンスの問題の現在の性質を理解することです。
一般的なカテゴリには次のものがあります：
- 「ペグされたCPU」が原因で可用性に影響が出ています。たとえば、すべてのスケジューラが全面的に100％で実行され、スループットが停止または大幅に低下しています。
- 「通常よりも高い」CPU使用率によるパフォーマンスの低下。そのため、固定されていませんが、CPUは通常よりも高い割合で実行されており、おそらくパフォーマンスに影響を与えています。
- CPUパフォーマンスの問題のもう1つの一般的なカテゴリは、ワークロードが互いに競合している「勝者と敗者」のシナリオです。おそらく、レポートクエリの並列実行が原因でスループットが低下しているOLTPワークロードがあります。
- 別の問題は、システムの全体的な容量とスケーラビリティの制限が特定の時点で発生する転換点に遭遇することである可能性があります。
これらの包括的なカテゴリを出発点として言及しますが、多くの場合、これらの問題には大きな依存関係があり、1つのカテゴリが他のカテゴリに溶け込む可能性があることを知っています。そうは言っても、最初のステップは症状と問題をできるだけ明確に定義することです。
現在の状態を検証する
問題が過去に発生した場合でも、現在発生している場合でも、システム、ワークロード、および構成に関する背景情報をできるだけ多く取得することが重要です。ベースラインとRun-Bookを使用している場合、理想的には、この情報の多くをすでに追跡しています。そうでない場合は、危機の真っ只中の午前2時にこれらの質問に対する回答をどれだけ早く得ることができるかを自問してください。
次のサブセクションでは、CPUパフォーマンスの問題について私が通常関心を持っている重要なデータポイントについて説明します。
- ソケットとコアはいくつですか？
- ハイパースレッディングは有効になっていますか？
- プロセッサモデル、アーキテクチャ（32ビット/ 64ビット）とは何ですか？
- これは仮想ゲストですか？
- もしそうなら、あなたは今、あなたがリソースを共有しているホストと他の仮想ゲストについての詳細にも興味を持つでしょう。
- CPU関連の設定は有効ですか？
- たとえば、Hyper-V CPU
- ゲスト間で割り当てられるvCPUの数はいくつですか？
- このゲストにはいくつのvCPUがありますか？
- 問題が発生する前に、ゲストは最近新しいホストに移行しましたか？
- 最大並列度設定
- 並列処理オプションのコストしきい値
- プロセッサアフィニティ設定
- 優先ブースト設定
- 最大ワーカースレッド設定
- 軽量プーリング設定
- 電源オプションの設定とは何ですか？ （OSレベル、VMホストまたはBIOS制御）
- 高性能、バランスの取れた、省電力？
物理サーバーの詳細
仮想サーバーの詳細
予約、VMware CPU予約、Hyper-V CPU相対ウェイト、およびVMwareCPUシェア。
SQLServerインスタンス構成設定
最初の3つの構成については、さらに説明が必要な場合があります。これらの設定に関して絶対的なものはめったにありません。
「優先度の向上」などの最後の3つの設定については、デフォルト以外の値になっていることがわかった場合は、より多くの背景情報と履歴を確実にプッシュします。
CPU電源オプション設定
「ハイパフォーマンス」より下の電源オプション設定は依然として非常に一般的であり、SQLServerインスタンスをホストするサーバーでは無視しないでください。
リソースガバナーの構成
- デフォルト設定を超えて構成されていますか？
この機能を使用しているお客様に出会うことはほとんどありませんが、使用されているかどうかを確認するのは簡単で、実際にデフォルトを超えて構成されている場合は価値があります。
SQLServerエラーログとWindowsイベントログ
- 異常な警告やエラーが表示されますか？
CPUの問題についてエラーログとイベントログを調べるのはなぜですか。アップストリームの問題により、SQLServerでダウンストリームのパフォーマンスの問題が発生する場合があります。上流のルートにいるときに、クエリの調整や新しいインデックスの追加に時間を無駄にしたくない場合。これは、ハードウェアコンポーネントの劣化の問題であるためです。
「それはSQLServerですか？」と答えます
聞いてみると当たり前のように聞こえますが、原因が実際にはSQL Serverでない場合は、SQLServerのCPUの問題のトラブルシューティングにかなりの時間を費やしたくないでしょう。
代わりに、少し時間を取って、どのプロセスが最も多くのCPUを消費しているかを確認してください。次のようないくつかのオプションから選択できます。
- プロセス：％ユーザー時間（ユーザーモード）
- プロセス：％特権時間（カーネルモード）
- タスクマネージャー
- Process Explorer
- sys.dm_os_ring_buffersまたはシステムで実行されている特定のSQLServerインスタンスのシステムヘルスセッションを介した最近のCPU情報
SQL Serverであり、複数のSQL Serverインスタンスから選択できる場合は、ホスト上の適切なSQLServerインスタンスのトラブルシューティングを行っていることを確認してください。これを行うには、SELECT SERVERPROPERTY('processid')を使用するなど、いくつかの方法があります。 PIDを取得し、それをタスクマネージャーまたはProcessExplorerに関連付けます。
SQL Serverであることを確認したら、ユーザー時間または特権（カーネル）時間が長くなりますか？繰り返しますが、これはProcess：％Privileged Time（sqlservrオブジェクト）およびWindowsタスクマネージャーまたはProcessExplorerを介して確認できます。
カーネル時間の問題が発生することはまれですが、それでも、標準のユーザー時間のCPUトラブルシューティングの問題とは異なるトラブルシューティングパスが必要です。カーネル時間が長くなる原因としては、フィルタードライバー（ウイルス対策、暗号化サービス）の障害、ファームウェアの更新とドライバーの古さや欠落、I/Oコンポーネントの欠陥などが考えられます。
CPUコンシューマーを特定する
どのSQLServerインスタンスがシステムでユーザー時間のCPU使用率を高めているかを検証すると、使用できる事前に用意されたクエリの例がWeb上にたくさんあります。
以下は、パフォーマンスの問題でさまざまな形で一般的に使用されるDMVのリストです。これをQ＆A形式で構成して、アクセスする理由を説明しました。
- sys.dm_exec_requests
- sys.dm_exec_sql_text
- sys.dm_exec_sessions
- sys.dm_exec_connections
- sys.dm_exec_query_plan
- sys.dm_os_waiting_tasks
- sys.dm_exec_query_stats
- total_worker_timeで集計
- execution_countで平均を定義する
- アドホックワークロードの場合は、query_hashでグループ化できます
- plan_handleとsys.dm_exec_query_planを使用してプランを取得します
- sys.dm_os_tasks
- session_id、request_idで並べ替え
- sys.dm_exec_query_plan
- プランのオペレーターを見てください。ただし、これは単なる推定プランであることに注意してください
- sys.dm_exec_query_stats
- total_elapsed_timeがtotal_worker_timeよりも短いフィルター
- ただし、これは、リソースの待機が原因で期間が長くなるブロッキングシナリオではフォールスネガティブになる可能性があることに注意してください
現在実行中のリクエストとそのステータスは何ですか？
何を実行していますか？
どこから来たの？
その推定計画は何ですか？ （ただし、CPUに制約のあるシステムではxmlを細断処理することに注意してください）
リソースを待っているのは誰ですか？彼らは何を待っていますか？
最後の再起動以降、CPU時間を最も多く使用しているクエリはどれですか？
このクエリは並列処理を使用していますか？
パターンを一致させて解決する
あなたはおそらくこの特定のステップを笑っています–これは最も関与する可能性があるためです（そしてSQL Serverの専門家が有能に雇用されているもう1つの理由です）。いくつかの異なるパターンと関連する解決策があります。そのため、この投稿の最後に、過去数年間に見た、より一般的なCPUパフォーマンスの問題のドライバーのリストを示します。
- 高I/O操作（そして私の経験では、これはCPUの最も一般的なドライバーです）
- カーディナリティ見積もりの問題（および関連するクエリプランの品質の低下）
- 予期しない並列処理
- 過度のコンパイル/再コンパイル
- 計算集約型のUDF呼び出し、シュレッダー操作
- 苦悶する行の操作
- 同時メンテナンスアクティビティ（例：FULLSCANを使用した統計の更新）
私が特定した各領域には、調査すべき多くの関連する作業があります。統合されたリソースに関しては、Sunil Agarwal、Boris Baryshnikov、Keith Elmore、Juergen Thomas、Kun Cheng、BurzinPatelが執筆した「SQLServer2008のパフォーマンス問題のトラブルシューティング」技術記事が依然として優れていると思います。
概要
他の方法論と同様に、その利用には境界があり、即興で正当化される領域があります。この投稿で説明した手順を厳密なフレームワークとして使用することを提案しているのではなく、トラブルシューティング作業の開始点と見なしていることに注意してください。経験豊富なSQLServerの専門家でさえ、新人のミスを犯したり、最近のトラブルシューティングの経験に偏ったりする可能性があるため、最小限の方法論で、間違った問題のトラブルシューティングを回避できます。