パフォーマンスの問題を調査しているときに、CXPACKETSへの流入があり、並列処理のコストしきい値と、おそらくMAXDOPを調べる必要があるかもしれないと示唆しています。
MAXDOPに大幅な変更を加える前に、SQL Server 2008のCXPACKET Waitsパフォーマンスチューンへの回答での@mrdennyの回答や、CXPACKET待機への対処からの@ aron-Bertrandの回答-コストしきい値の設定など、他の多くのアドバイスに従っています平行性について。統計情報を毎晩完全に更新するために、メンテナンスに追加しました。これは賢明な動きのように感じます。
ただし、コストのしきい値に変更を加えることはまだ私を悩ませるものです。
並列処理のコストしきい値はどの時点で変更する必要がありますか？（クエリとワークロードのコストを調べた後）このコストに変更を加えた例はありますか？
これが前の質問で回答されたものである場合は謝罪します。
ありがとう！
回答:
MAXDOP = 1を使用することは助けになるかもしれませんが、それは大きな銃です。実際の問題は、インデックスの有用性である可能性があります。おそらく、新しいインデックスまたは別のインデックスが問題を解決するでしょう。
デニー氏とアーロンバートランドのコメントに続いて、その接続の他の待機がCXPACKET待機の原因である可能性が高いことを発見しましたか？
Jonathan Kehayiasさんは、並列処理の経験を評価し、より思慮深い決定を下すのに役立つ可能性のあるクエリを提案しました。しかし、ジョナサンとポールホワイトの間の会話も読む必要があります。
https://www.sqlskills.com/blogs/jonathan/tuning-cost-threshold-for-parallelism-from-the-plan-cache/
デフォルト設定の0（使用可能なすべてのスレッドを使用）は危険である可能性があるため、最初にMAXDOP設定を確認することをお勧めします。使用可能なすべてのスレッドを消費する暴走クエリはスレッドの枯渇につながるためです。
サーバーインスタンスのMAXDOP設定を計算する方法については、こちらの回答を参照してください。
並列処理のコストしきい値は、オプティマイザが並列処理を検討する前に、クエリの最小コストをどの程度にする必要があるかを示します。
CXPACKETが待機するのは、クエリに関連する問題が原因で発生する単なる症状です-統計が古くなっている、またはインデックスが見つからないために、計画が不適切または異なっています。
あなたは使用することができますsys.dm_exec_cached_plansし、sys.dm_exec_query_planで説明したようにプランキャッシュから地雷情報にDMVのプランキャッシュから「並列処理のためのコストしきい値」チューニングジョナサンによると、 並列処理のためのコストしきい値。
cost threshold for parallelismリソース調整クエリを使い尽くし、インデックスと統計のメンテナンスを実行し、クエリが効果を発揮する可能性のある欠落インデックスがないかどうかを確認しない限り、をデフォルトのままにしておくことをお勧めします。
注：Maxdop設定はOPTION (MAXDOP n)、サーバー全体の設定を上書きするクエリレベルでも適用できます。