SQL Server 和超线程的当前智慧？

Question

很多文章（请参阅Slava Oks 的原始 SQL 2000 文章和Kevin Kline 的 SQL 2005 更新）建议在 SQL 服务器上禁用超线程，或者至少在服务器上启用超线程之前测试您的特定工作负载。

随着真正的多核处理器取代超线程处理器，这个问题逐渐变得不那么重要，但目前在这个问题上的智慧是什么？这个建议是否对 SQL 2005 64 位、SQL 2008 或 Windows Server 2008 有任何改变？

理想情况下，这应该在登台环境中提前进行测试，但是对于已经启用 HT 的服务器呢？如何判断我们遇到的性能问题是否与 HT 相关？与我在提高 SQL 性能时通常追求的所有其他事情相反，是否有一些特定的 perfmon 计数器组合可能会指向这个方向？

编辑：这特别有吸引力，因为我的一些高 cpu 服务器有可能得到全面改进，但客户端将希望看到一些具体的东西，以帮助我确定哪些服务器真正可以从禁用超线程中受益。当然，传统的性能故障排除正在进行中，但有时任何一点点帮助。

Answer 1

在 SQLOS 中，为 SQL Server 看到的每个逻辑处理器创建了一个调度程序。启用超线程后，这相当于将调度程序加倍。SQLOS 的目的之一是最小化和防止发生上下文切换，这就是为什么只为每个逻辑处理器创建一个调度程序。一旦 SQLOS 创建了调度程序，工作线程的总数就会在调度程序之间分配。SQLOS 实现了一种协作调度形式，因为工作程序在需要不可用资源时让出调度程序，或者达到其执行量以允许其他工作程序在调度程序上执行。这将上下文切换保持在最低限度，因为调度程序正在执行工作并且它们是一对一的。

了解这一背景后，超线程的工作方式与 SQLOS 专门设计的功能有所不同。具体来说，并行性对于超线程可能会产生问题，并可能导致高 CXPACKET 等待，因为 SQLOS 可能会尝试在 DOP 8 上运行 DOP 4 系统上的查询。如果您的 CPU 利用率较低，您可能不会注意到，但 CPU 利用率越高，问题就越多。我最近在 twitter 上讨论了这个问题，关于它是否会有所帮助或伤害，共识是“这取决于”。

如果您的服务器上有很多信号等待，但 CPU 利用率较低，您可能会看到启用超线程的好处，这将使您的内部调度程序加倍并使工作人员分散得更多，这意味着他们不会等待在可运行队列中执行只要。但是，如果您的工作负载大量使用并行性，您会在 sys.dm_os_wait_stats 中获得大量 CXPACKET 等待，您可能会考虑禁用超线程以查看它是否会减少您的等待。