我应该禁用超线程吗

Question

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

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

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

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

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

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

最终，我在互联网上发现的大部分内容都表明超线程和 SQL 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 个，请尝试关闭超线程：

优化 SQL Server CPU 性能作者：Zach Nichter