CPU利用率低但信号等待时间高

我有一台具有16个CPU的服务器，该服务器配置max degree of parallelism为8且max worker threads设置为零。

在给定的一个小时内，我的信号等待时间为20％，但在此期间我的OS CPU利用率从未超过25％。有人可以解释为什么我的信号等待如此之高吗？

我的供应商拥有同类最佳的评分系统，希望我们的信号等待率不超过10％，否则我们会感到不高兴。我该如何解决此问题（不添加其他CPU）？

• 每个NUMA节点我们的CPU不超过8个，因此跟踪标志8048不适用。
• 最大实例等待量是CXPACKET（70％），然后是PREEMPTIVE_OS_PIPEOPS（20％）
• cost threshold for parallelism设置为50。我应该提高它吗？要什么？
• 这是专用于SQL Server的物理计算机（不是VM）。
• 我正在使用监视工具来识别最频繁运行的查询和过程。我要查看较高的CPU，较高的I / O或较高的持续时间吗？通常，我们的应用程序是I / O密集型的，因此我会调整高I / O。但是，由于问题是信号等待，我是否需要查看较高的CPU？
• 我希望避免将Max Vernon的建议降低MAXDOP到4，因为该应用程序会执行一些需要额外线程的仓库样式查询。

_{Aaron对问题的评论产生了社区Wiki答案。}

除非您遇到性能问题，否则高比例的CXPACKET等待可能仅表示大部分查询正在并行执行，而实际上并不是问题。

• 什么是CXPACKET等待类型，如何减少它？

较高的CPU可能是一个指标，但是从您的解释来看，我要说的是看看持续时间长但CPU较低的查询。CXPACKET有时，该等待与一个查询相关联，该查询等待所有线程完成才能合并结果（数据偏斜）。

如果能够修改查询和过程，则可MAXDOP以为需要它的仓库任务设置较高的值，而将全局范围设置为MAXDOP较低。但是，我只会在不得已的情况下这样做。当您用尽所有可能性，或者您无法对代码，查询或数据库模式进行更改时，您才真正想做这些类型的显式提示。