SQLサーバーでのCXPACKET待機
最近、SQL Serverデータベースでパフォーマンスの問題が発生しており、以下に示すように待機を示す2つのクエリがあります。このサーバーのデータベースの1つはAlways Onレプリカのメンバーですが、負荷は他のデータベースにあります。
最初のクエリは、Paulsのクエリからの場合、10秒間の待機統計を収集して差と2番目のリストを計算する私のクエリです。 https://www.sqlskills.com/blogs/paul/wait-statistics- or-please-tell-me-where-it-hurts /
違いについては、CXPACKETとRedo_Thred_Pending_Workの待機を無視して、PageIOLatch_SHの待機の根本的な原因（おそらくインデックス付けが不十分）に対処する必要があるのでしょうか。 MAXDOP値は0で、サーバーには36コアがあります。
さまざまな要因が原因である可能性のあるパフォーマンスの問題の性質を私たちが知らない限り、コメントするのは非常に困難です。
また、キャプチャした待機には2つの異なる手段があります。特定のクエリの実行について計算した時間中に見られた待機のために収集されたもの。 Paul Randalからのその他のものは、前回の再起動以降にCXpacketsをポイントしたものであり、必ずしも問題を示しているわけではありません。最後の再起動以降に実行されていたすべてのプロセスの待機統計を収集したこと。したがって、サーバーの全体的なパフォーマンスのトラブルシューティングを行うのか、待機がキャプチャされたクエリだけをトラブルシューティングするのかによって異なります。
また、SQLサーバーのバージョンによっては、CXpacketsの待機を解釈するためのより良い方法があります。 SQL 2016 SP2以降では、cxconsumerも使用できるようになったため、CXpacketの待機統計の良し悪しを区別できます。詳細については、Aaron Bertrandによる here を参照してください。
また、調整する論理プロセッサに応じて、最高の魔法の数でテストする必要があるMAXDOP 0があることもわかります。私の経験とMSのサポートによると、ほとんどの数値で機能する最も優れた魔法の数は4〜8であり、論理プロセッサは8より大きい。
MAXDOPに加えて、サーバーの並列処理のコストしきい値を確認することを忘れないでください。 5デフォルトではうまく機能しません。
ただし、インデックス作成戦略のような他の要因も調べて、それらを調整する機会を見つけ、パフォーマンスの向上に役立ててください。
私は基本的に@KASQLDBAの答えを繰り返しますが、max degree of parallelismおよび最初のステップとして、並列処理のコストしきい値。
MAXDOP値は0で、サーバーには36コアがあります。
これを0のままにしないでください。これをより妥当なレベルに調整します。あなたは従うことができます Microsoftの推奨事項 およびそれを8または最大数に設定しますNUMAあたりの論理プロセッサの数のいずれか少ない方。または、@ KASQLDBAが上記の回答で述べたように、 dbatools.io Test-DbaMaxDop コマンドを試して、実行せずに推奨を取得するすべての脚の仕事。
この設定を0のままにすることの問題は、並列プランがサーバー上のすべてのコアを使用することです。デフォルトのままにすると、十分な並列プランが実際にサーバーのCPUリソースを枯渇させ、システム全体の速度を低下させる可能性があります。これは非常に悪いので、サーバー全体が一時的にエンドユーザーにフリーズし、あらゆる種類の騒動を引き起こします。表示されているCXPacketの待機は、この設定が正しく構成されていないことを示している可能性があります。
この回答の冒頭で述べたように、並列処理のコストしきい値も調整してください。 Erik Darlingは すばらしい記事 で、この設定とは何か、どのように機能するか、そしてその数値が何を意味するのかを概説し、50に設定してそこから調整することから始めることをお勧めします。