我应该禁用超线程

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

结果，我注意到的一件事是我们在上下文切换中有大量的峰值。下面是一个5分钟的示例，但是这种模式在一天中非常普遍。

如您所见，它的峰值很规律。现在，我对此的理解使我相信这将是CPU压力的结果。但是在这段时间里，勉强能超过60％。

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

使长话短说。超线程是否可能是上下文切换中这种尖峰的罪魁祸首？上下文切换是否有可能对我的并行查询产生负面影响？我应该在我的环境中禁用超线程吗？

更新尽管此特定情况正在我的环境中发生，但其核心问题是更普遍的。高级别的上下文切换对并行查询有多大影响？超线程会导致这种问题吗？

最终，我在互联网上发现的大多数内容最终都表明超线程和SQL Server不是好朋友，但是大多数情况下，这些信息都是过时的。

我的系统有很多配置问题，因此在这里我将解决这些问题，以便将它们排除在外。我们在操作系统和生物级别上都具有性能的电源设置。我们的Maxdop设置为8，并行性的成本阈值为25。我们有32个逻辑内核和16个物理内核。同样，在大多数情况下，这也是数据仓库的负载情况。

通常只表示某些查询正在以并行性执行；尽管服务器中的CXPACKET等待可能不是其他问题的征兆，但它们并不是问题的直接征兆。

如果服务器托管的数据仓库或报告类型的数据库接收少量查询但处理大量数据，则并行性可以大大减少执行这些查询所需的时间。但是，相反，如果服务器托管的OLTP数据库具有许多小的查询和事务，则并行性可能会破坏吞吐量并对性能产生负面影响。

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

sys.dm_os_latch_stats DMV包含有关实例中已发生的特定闩锁等待的信息，并且如果最大闩锁等待之一是ACCESS_METHODS_DATASET_PARENT，则与CXPACKET，LATCH_ *和SOS_SCHEDULER_YIELD等待类型一起用作顶级等待，即系统上的并行性是查询执行过程中出现瓶颈的原因，因此可能需要减小“最大并行度” sp_configure选项才能解决问题。

这篇《 TechNet杂志》的文章很旧，但确实说如果每个处理器每秒超过5000个，请尝试关闭超线程：

Zach Nichter 优化SQL Server CPU性能