CPU使用率は低いが信号待機が多い

私は、16のCPUを搭載したサーバーで、a max degree of parallelismが8、max worker threads設定が0に設定されています。

所定の時間、私の信号待機は20％でしたが、その間の私のOS CPU使用率は25％を超えることはありませんでした。誰かが私の信号待機が非常に高かった理由を説明できますか？

私のベンダーはクラス最高のスコアリングシステムを使用しており、信号待機が10％以下であると予想します。（CPUを追加せずに）これを修正するにはどうすればよいですか？

• NUMAノードごとに8個を超えるCPU はないため、トレースフラグ8048は適用されません。
• 最大のインスタンス待機はCXPACKET（70％）、次にPREEMPTIVE_OS_PIPEOPS（20％）
• cost threshold for parallelism50に設定されています。上げる必要がありますか？何に？
• これは、SQL Server専用の物理マシン（VMではない）です。
• 監視ツールを使用して、最も頻繁に実行されるクエリとプロシージャを特定しています。高CPU、高I / O、または高継続時間を確認しますか？通常、アプリはI / Oを集中的に使用するため、高いI / Oを調整します。しかし、問題はシグナル待機であるため、CPU使用率が高いことを確認する必要がありますか？
• アプリが追加のスレッドを必要とするウェアハウススタイルのクエリを実行するため、4 に下げるというMax Vernonの推奨を回避したいと思ってMAXDOPいました。

_{Aaronによる質問へのコメントから生成されたコミュニティWiki回答。}

パフォーマンスの問題が発生していない限り、CXPACKET待機の割合が高いのは、クエリの大部分が並列していて、実際には問題がないことを示すものにすぎない場合があります。

• CXPACKET待機タイプとはどのようなもので、どのように削減しますか？

高いCPUは指標になる可能性がありますが、あなたが説明したことから、最初は長い期間で低いCPUのクエリを見てみます。CXPACKET待ち時間は、時にはそれが結果（データの偏り）をマージすることができます前に、クエリが最後まですべてのスレッドを待っているに関連付けられています。

クエリとプロシージャを変更できる場合は、それMAXDOPを必要とする倉庫タスクに高い値を設定し、グローバルにMAXDOP低い値を設定できます。ただし、これは最後の手段としてのみ行います。すべての可能性を使い果たした場合、またはコード、クエリ、またはデータベーススキーマに変更を加えることができない場合にのみ、これらのタイプの明示的なヒントを作成したいだけです。