web-dev-qa-db-ja.com

高いCXPACKETおよびLATCH_EX待機

作業中のデータ処理システムのパフォーマンスに問題があります。大量のCXPACKETおよびLATCH_EX待機イベントを示す1時間のペリロイドから待機統計を収集しました。

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

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

このような待機統計の原因は何か、このパフォーマンスの問題の根本的な原因を調査するためにどのような行動を取るべきかを誰かが提案できますか？

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

sql-serverperformanceparallelismwait-typesquery-performance
13
stumct

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

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

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

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

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

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

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

CXPACKET待機タイプを深く理解する必要がある場合は、 SQL ServerのCXPACKET待機タイプのトラブルシューティング の記事をお読みください。

8
Gustav

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

SQL Serverのパフォーマンスを分析する方法 が役立つかどうかを確認します。

7
Remus Rusanu

上記のリンクを読み、「並列処理の最大度」の設定を0から8などに変更する可能性が最も高いことに加えて、並列化するクエリとそのコストを絞り込む必要があります。

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

以下は、Brent Ozarのすばらしいビデオです。 CXPACKETとMAXDOPの芸術をマスターする

目標は、CXPACKETの待機時間を50％以下にすることです。幸運を！！

3
drumatix