高いCXPACKETおよびLATCH_EX待機

私が取り組んでいるデータ処理システムのパフォーマンスに問題があります。大量のCXPACKETおよびLATCH_EX待機イベントを示す1時間のperoidから待機統計を収集しました。

システムは3つの処理SQL Serverで構成され、多数の数値計算と計算を実行してから、中央のクラスターサーバーにデータを供給します。処理サーバーでは、一度に最大6つのジョブを実行できます。これらの待機統計は、ボットネックを引き起こしていると思われる中央クラスターに関するものです。中央クラスタサーバーには、16コアと64GB RAMがあります。MAXDOPは0に設定されます。

CXPACKETは実行中の複数の並列クエリからのものであると思いますが、LATCH_EX待機イベントが何を示しているのかわかりません。私が読んだことから、これは非バッファ待機かもしれませんか？

これらの種類の待機統計の原因が何であるか、このパフォーマンス問題の根本原因を調査するために私が取るべき措置は何ですか？

上位のクエリ結果は合計待機統計であり、下位のクエリ結果は1時間の統計です。

CXPACKETにはLATCH_XXを伴うことができます（おそらくPAGEIOLATCH_XXまたはSOS_SCHEDULER_YIELDも同様に）。これが当てはまる場合（質問に基づいていると思う）、ハードウェアに適合するようにMAXDOP値を下げる必要があります。

これに加えて、（SQL Serverで何かを変更する前に）CXPACKETの待機統計値が高くなっている原因を診断するための推奨手順を次に示します。

• MAXDOPを1に設定しないでください。これは決して解決策ではありません。

• クエリとCXPACKETの履歴を調査して、それが1回または2回発生したものかどうかを理解し、判断します。これは、正常に機能しているシステムの例外である可能性があるためです。

• クエリで使用されるテーブルのインデックスと統計をチェックし、それらが最新であることを確認します

• 並列処理のコストしきい値（CTFP）を確認し、使用する値がシステムに適切であることを確認してください

• CXPACKETにLCK_M_XX（通常はIO_COMPLETIONおよびASYNC_IO_COMPLETIONが付属）が付属しているかどうかを確認します。この場合、並列性はボトルネックではありません。これらの待機統計をトラブルシューティングして、問題の根本原因と解決策を見つけます。

CXPACKET待機タイプを詳細に理解する必要がある場合は、SQL Serverの記事「CXPACKET待機タイプのトラブルシューティング」を読むことをお勧めします

SQL Serverでのラッチの競合の診断と解決を読むは、このトピックに関する最も包括的なペーパーです。sys.dm_os_latch_stats競合がどのラッチタイプであるかを調べて確認する必要があります。

SQL Serverのパフォーマンスを分析する方法を読んで、何らかの方法で役立つかどうかを確認してください。

上記のリンクを読んで、「Max Degree of Parallelism」設定を0から8などに変更する可能性が高いことに加えて、どのクエリが並列になり、そのコストがどれくらいになるかを絞り込んでください。

この変更の影響を確認した後、「並列処理のコストしきい値」を変更して、並列処理を微調整することも検討できます。

Brent Ozarが提供するすばらしいビデオをご覧ください。CXPACKETとMAXDOPのアートをマスターする

目標は、CXPACKETの<= 50％の待機時間です。幸運を！！