待機統計の概要

2014年に、私はここで一連のブログ投稿を開始して、特定の待機タイプと、それらが何を意味し、何を意味しないかについて話しました。それは私が維持する待機ライブラリとラッチライブラリを作成するというアイデアを私に与えました（これらについては後で詳しく説明します）。

これを読んで「彼は何について話しているのか」と考えているなら。その後、この投稿はあなたのためです。待機統計を紹介し、SQLServerのワークロードパフォーマンスのトラブルシューティングに統計がどれほど重要であるかを説明します。

スケジュール

SQL Serverの内部コードの実行は、スレッドと呼ばれるメカニズムを使用して行われます。。各スレッドはSQLServerコードを実行でき、クエリが並行して実行されると、複数のスレッドが連携します。これらのスレッドは、SQL Serverが使用できるプロセッサコアの数に応じて、SQLServerの起動時に作成されます。

スレッドはスケジューラーに配置されますクエリが開始されたとき、プロセッサコアごとに1つのスケジューラがあり、クエリが終了するまでそのスケジューラから移動しないでください。スケジューラには、3つの基本的な「部分」があります。

プロセッサ 、現在コードを実行しているスレッドが1つだけあります。
ウェイターリスト 、基本的にスタックしているすべてのスレッドがあり、特定のリソースが利用可能になるのを待っています。
実行可能なキュー 、実行できるがプロセッサに到達するのを待っているすべてのスレッドがあります。

スレッドは、クエリが終了するまで、状態1から2、3から1に移行します。

待つ

私たちの観点からすると、スケジューリングの最も興味深い部分は、スレッドが続行する前にリソースを待機する必要がある場合です。この例は次のとおりです。

スレッドはページを読み取る必要があり、ページはメモリにないため、スレッドは非同期の物理I / Oを発行し、I/Oが完了するまでプロセッサから離れるまで待機する必要があります。
スレッドは、それを読み取るために行の共有ロックを取得する必要がありますが、別のスレッドは、行を更新している間、競合する排他ロックをすでに保持しています。

スレッドが取得できないリソースの必要性に遭遇した場合、停止してリソースが使用可能になるのを待つしかありません（スレッドがリソースの使用可能性について通知されるメカニズムは、この記事の範囲を超えています）。その場合、SQL Serverは、スレッドが待機しなければならなかった理由を記録します。これは、待機タイプと呼ばれます。。この例は次のとおりです。

スレッドがページがメモリに読み込まれて読み取れるようになるのを待機している場合、待機タイプは PAGEIOLATCH_SHです。（スレッドが変更されるページを待機している場合、待機タイプは PAGEIOLATCH_EXです。）。
スレッドが行の共有ロックを待機している場合、待機タイプは LCK_M_Sです。（ロックモード共有）

SQL Serverは、スレッドが待機する必要がある時間も追跡します。これはリソース待機時間と呼ばれます、通常は待機時間と呼ばれます。

待機統計

いくつのスレッドがどのリソースを待機し、平均してどのくらいの時間待機したかを示す一連のメトリックは、統計の待機と呼ばれます。。この情報は、パフォーマンスのボトルネックがどこにあるかを簡単に確認できるため、ワークロードのパフォーマンスのトラブルシューティングに非常に役立ちます。

基本的な考え方は、SQL Serverには、スレッドを停止して待機する必要がある理由と、スレッドが何を待機しているのかに関する情報があるということです。したがって、トラブルシューティングをどこから開始するかを推測するのではなく、待機統計を注意深く分析することで、通常、進むべき方向を示すことができます。

たとえば、サーバーでの待機の大部分が PAGEIOLATCH_SHである場合、これは、サーバーにメモリ不足があるか、非クラスター化インデックスを使用する代わりに大規模なテーブルスキャンを実行するクエリがあるか、基盤となるI / Oサブシステムに問題があるか、またはその他の多くの理由があることを示している可能性があります。

待機の種類は多数ありますが、ほとんどの場合、頻繁に発生することはないため、サーバーに何度も表示されるコアセットがあります。これらの意味と調査方法を理解することは重要です。そのため、私が「ひざまずくパフォーマンスチューニング」と呼んでいるものに屈することなく、実際には問題ではない問題を修正するために時間と労力を浪費することはありません。私はここに一連のブログ投稿を書き、そこで詳細を説明しました。また、Aaron Bertrandは、昨年の待機統計トップ10の要約投稿も書きました。

追跡待機

待機を追跡する方法はいくつかあります。最も簡単なのは、 sys.dm_os_waiting_tasks を調べるスクリプトを使用して、サーバーで現在発生している待機を確認することです。 DMV。これを行うためのスクリプトはここにあり、待機ライブラリに自動生成されたURLが含まれています。

もう1つの方法は、 sys.dm_os_wait_stats を調べるスクリプトを使用して、サーバー全体の合計待機統計を確認することです。 DMV。これを行うためのスクリプトはここにあり、待機ライブラリに自動生成されたURLが含まれています。ただし、サーバーの起動以降に発生したすべての待機が表示されるため、この方法には注意する必要があります。より良い方法は、30分などの短い間隔で待機を追跡することです。これを行うためのスクリプトは、ここにあります。

新しいAzureDataStudioツールのServerReportsアドインを使用し、SQLServer2017以降のクエリストアを使用して待機統計を取得することもできます。

指標を収集した後でも、待機タイプの意味を理解する必要があることを忘れないでください。

リソースを待つ

これを支援するために、またMicrosoftには待機統計の解釈方法に関するドキュメントがないため、2016年に、数百の一般的な待機タイプとそのトラブルシューティング方法の詳細を含む待機タイプライブラリをリリースしました。 https://www.SQLskills.com/help/waitsでライブラリにアクセスできます。そして2017年に、SentryOneは、ライブラリ内の各ページのインフォグラフィックを提供する自動システムを作成しました。これを使用して、関心のある待機タイプが本当に一般的なものであるかどうかをすばやく確認できます（詳細については、この投稿を参照してください）。。 PAGEIOLATCH_SHのインフォグラフィックの例を以下に示します。待機タイプ：

横軸は、前の暦月にこの待機を経験したインスタンスの割合（SentryOneによってリモートで監視）のスケール（線形と対数の間で切り替え可能）であり、縦軸は、それを経験したインスタンスの時間の割合です。 waitには、実際にはその待機タイプを待機しているスレッドがありました。

待機を理解するのに役立つもう1つのリソースは、Pluralsight用に記録したオンライントレーニングコースです。こちらをご覧ください。

少なくとも、上記の「待機統計」セクションと「待機待機の追跡」セクションにあるさまざまなブログ投稿を読む必要があります。

SentryOneツールを使用した待機の追跡

SQL Sentryは、インスタンスレベルの待機を時間の経過とともに自動的に追跡するため、「実際に」高い待機をキャッチする必要はありません。誰かが昨日の午後のシステムの停滞や先週の火曜日にタイムアウトしたレポートについて不満を言ったのですか？問題ない。任意の時点または範囲にわたるすべての待機を掘り下げて、その時点で収集された他のさまざまなパフォーマンスメトリックと相関させることができます。これは、バックアップやデータベースI / Oアクティビティなど、ダッシュボード上の他のトレンドであり、すべてにジャンプします。同じウィンドウで実行されていた上位のSQLコマンド、長時間実行されているブロッキングを調査している、またはベースラインを使用して待機プロファイルを他の期間と比較している。

収集されるまたは収集されない待機をカスタマイズしたり、視覚的に表示されるカテゴリを変更したり、特定の待機シナリオに対するインテリジェントなアラートや応答を構築したりすることもできます。お客様の多くは、SQL Sentryを使用して、待機に関連する実際のパフォーマンスの問題に焦点を当てています。これにより、通常のSQLServerスレッドアクティビティである多くのノイズを無視できるようになります。

概要

上記の情報からわかるように、SQL Serverでは常に待機が発生します。これは、スレッドスケジューリングとマルチスレッドシステムが機能する方法だからです。これらはトラブルシューティングツールボックスで最も強力なツールの1つであるため、まだ使用していない場合は、今が開始するときです。学習曲線は短く急です。さまざまなクエリやツールを数回実行すると、すぐにコツをつかむことができます。次に、ガイドを読んで、待機していることを確認します。それらが問題ではないかどうかを判断します。

トラブルシューティングをお楽しみください！