PAGEIOLATCH待機タイプ
この待機タイプがどれほど深刻であるかをよりよく理解しようとしています。私はsp_WhoIsActiveストアドプロシージャを使用しています。私たちのDBAは、この待機タイプについてあまり知らないようです。しかし、ストアドプロシージャを実行するとよく表示されます。それらのほとんどはPAGEIOLATCH_SHですが、一部はPAGEIOLATCH_EX。それらが発生した場合、平均待機時間は20〜25ミリ秒の範囲にあるようです。
質問：
1）これは、メモリではなくI/Oの問題を示しているのでしょうか？
2）実際の問題と見なされる前に、誰かがこれを目にすることが予想される頻度についてのガイドラインはありますか？
この待機タイプのMicrosoftの定義は次のとおりです。
I/O要求にあるバッファのラッチでタスクが待機しているときに発生します。ラッチ要求は共有モードです。待機時間が長い場合は、ディスクサブシステムに問題がある可能性があります。
上記のように、過度のPAGEIOLATCH_SH待機タイプは、必ずしもI/Oサブシステムが根本的な原因であるとは限りません。インデックス管理の悪さ、メモリ不足、同期ミラーリングとAlwaysOn AG、論理/物理ドライブの誤解、ネットワークの問題/ネットワーク遅延、高Iを生成している別のプロセスによるI/Oサブシステムの過負荷/ Oアクティビティ。
過剰なPAGEIOLATCH_SH待機タイプの値を解決するには、次のいくつかを試してください。
- AlwaysOn AGで安全性の高いミラーリングまたは同期コミットの可用性の場合、増加/過剰
PAGEIOLATCH_SHが予想されることに注意してください - 頻繁に
PAGEIOLATCH_SH待機タイプの根本的な原因としてこれが見つかる可能性があるため、SQL Serverのクエリとインデックスを確認してください - I/Oサブシステムのトラブルシューティングに進む前に、メモリ負荷を確認します
この待機タイプの値が過度になる原因となっている実際のWordの状況を含め、この待機タイプの詳細が必要な場合は、 過剰なSQL Serverの処理PAGEIOLATCH_SH待機タイプ の記事をご覧ください。 。
PAGEIOLATCH_XX待機は、必ずしもIOサブシステムの問題を示しているわけではありません。これらの待機は、SQL Serverがデータページがディスクからメモリに読み込まれるのを待機しているときに記録されます。
Paul Randalからの詳細情報は、コメントで言及されているように、 ここ で見つけることができます。
したがって、IOサブシステムに問題があった場合、高レベルのPAGEIOLATCH_XX待機しますが、バッファプールがいっぱいであることによっても発生する可能性があるため、SQLサーバーは、ページがメモリに読み込まれる前にスペースが作成されるのを待機する必要があります。 SQL Serverと同じサーバーで実行されているアプリケーションは、SQL Serverが必要とする同じメモリを使用しようとすることにより、これらの待機を引き起こす可能性があります。
適切なインデックスでサポートされていない最適化されていないクエリも、多くのPAGEIOLATCH_XXクエリはシークの代わりにインデックススキャンを実行する可能性があるため待機します。これにより、IOが発生し、IOサブシステムからさらにページを読み取る必要があります。インデックススキャンは、SQL Serverが最適でないクエリプランを生成する原因となる古い統計によっても発生する可能性があります。
待機統計のベースラインを取得することは、ユーザー（またはDBAチーム）がパフォーマンス低下の原因を示している可能性があるパフォーマンスの低下の瞬間に待機統計を特定できるようにする優れた方法です。再びポール・ランダルはこれについて ここ について話し、一般的な待機統計のいくつかの説明も提供します。これらの説明は、参照用に常に開いているオフラインのチートシートに保存されています。