我应该禁用HyperThreading吗？

Question

背景最近，我一直在研究一些相当高的CXPacket等待时间，这使我不得不使用Sentry来非常密切地监视处理器活动。

因此，我注意到的一件事是，在下面的上下文切换中有大量的尖峰是一个5分钟的样本，但是这种模式在一天中非常常见。

正如你所看到的，它很有规律地上升。现在，我对此的理解将使我相信，这将是CPU压力的结果。然而，在这段时间里，几乎没有超过60%。

经过一些研究，我相信这是超线程的结果。我知道我以前读过一些超线程的危险。，但那是很久以前写的。

总而言之。在上下文切换中，超线程很可能是导致这种激增的罪魁祸首吗？上下文切换是否可能对我的并行查询产生负面影响？我应该在我的环境中禁用超线程吗？

虽然这个特定的事情发生在我的环境中，但它的核心问题更加普遍。高水平的上下文切换对并行查询的影响有多大？超线程会导致这种问题吗？

最终，我在互联网上发现的大多数信息都表明，超级线程和Server并不是好朋友，但大多数信息都是过时的。

我的系统有很多配置问题，所以我会在这里解决这些问题，这样就可以排除它们了。我们在两种操作系统和生物级别上都有性能上的电源设置。我们的Maxdop设置为8，并行性的代价阈值为25。我们有32个逻辑核心和16个物理核心。此外，这在很大程度上是一个数据仓库负载场景。

Answer 1

通常只表明某些查询是并行执行的；服务器中的CXPACKET等待并不是问题的直接迹象，尽管它们可能是另一个问题的症状。

如果服务器承载一个数据仓库或报告类型的数据库，该数据库接收低容量的查询，但处理大量数据，则并行性可以大大减少执行这些查询所需的时间。然而，如果服务器承载了一个包含大量小查询和事务的OLTP数据库，那么并行性可能会扼杀吞吐量并对性能产生负面影响。

只要有可能，最好隔离底层等待类型并排除故障，因为这将导致整个系统吞吐量的提高。同样，在大多数情况下，CXPACKET等待只是一个问题的症状，而不是实际问题。

sys.dm_os_latch_stats DMV包含有关实例中发生的特定锁存等待的信息，如果顶级闩锁等待中的一个是ACCESS_METHODS_DATASET_PARENT，则结合CXPACKET、LATCH_*和SOS_SCHEDULER_YIELD等待类型作为顶等待，系统上的并行级别是查询执行过程中瓶颈的原因，并且可能需要降低“最大并行度”sp_configure选项来解决这些问题。

“TechNet”杂志的这篇文章已经很久了，但它确实说，如果您的处理器每秒超过5000次，那么就尝试关闭超线程处理：

优化Server性能作者: Zach Nichter