目前对SQL Server和超线程的看法？

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

随着真正的多核处理器替代超线程处理器，该问题的重要性逐渐降低，但是在此问题上的最新见解是什么？对于SQL 2005 64位，SQL 2008或Windows Server 2008，此建议是否有任何更改？

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

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

在SQLOS中，将为SQL Server看到的每个逻辑处理器创建一个调度程序。启用超线程后，这等于使调度程序增加了一倍。SQLOS的目的之一是最小化并防止发生上下文切换，这就是为什么为每个逻辑处理器仅创建一个调度程序的原因。一旦SQLOS创建了调度程序，工作人员的总数就会在调度程序之间分配。SQLOS实现了一种协作调度的形式，在此过程中，工作人员会在不需要可用资源时产生调度程序，或者达到其执行范围，从而允许其他工作人员在调度程序上执行。由于调度程序正在执行工作，并且将它们一对一地绑定在一起，因此这使上下文切换降至最低。

了解该背景之后，超线程在某种程度上与SQLOS专门设计为起作用的方式相反。具体来说，并行性可能会给超线程带来问题，并且可能导致大量的CXPACKET等待，因为SQLOS可能会尝试在DOP 8上针对DOP 4系统的实际情况运行查询。如果您的CPU利用率较低，您可能不会注意到，但是CPU利用率越高，问题就越严重。我最近在Twitter上就此进行了讨论，共识是“它取决于”是有用还是有害。

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

实际上，超线程还没有消失，英特尔的新Nehalem四核芯片具有超线程。至于是否建议，一如既往，“取决于”，每种情况可能有所不同。

HT不太可能成为任何性能问题的根本原因，但是如果没有更多细节，很难说是什么。以较高的采样率（例如每30-60秒一次）进行一些perfmon会话，并获取cpu，数据和日志磁盘上的磁盘队列长度，页面预期寿命可以很好地衡量您是否有足够的内存。如果您的CPU持续超过80％，或者磁盘队列出现了三位数的增长，那么您就发现了问题所在。

HP DL360 G3上的SQL Server 2000：

我运行了六次报告，然后丢掉了最初的逃跑记录了最后五次。然后，我再次重新启动了数据库，并重新打开了超线程。我又运行了六次报告，保留了前五次运行的数据。

观察结果：

• 关闭超线程不会花费2倍的表观CPU使用率，而仅花费1.5倍。
• 关闭超线程可以使长时间运行的随机报表的运行速度平均快5.2％。

重复运行报告：

使用超线程：20.95％，21.1％，21.9％，20.8％，20.5％
运行时间（毫秒）：20282、21141、20188、22297、25282。平均21838

不使用超线程：29.4％，28.2％，29.1％，28.2％，27.1％
运行时间（毫秒）：20125、20156、19937、21656、21656。平均20706