很多文章(参见
Slava Oks’s original SQL 2000 article和
Kevin Kline’s SQL 2005 update)建议在sql服务器上禁用超线程,或至少在服务器上启用它之前测试特定工作负载.
随着真正的多核处理器取代超线程处理器,这个问题逐渐变得不那么重要了,但目前这个问题的智慧是什么呢？使用sql 2005 64位,sql 2008或Windows Server 2008时,此建议是否会发生任何变化？
理想情况下,这应该在暂存环境中提前进行测试,但对于已经通过HT启用生产的服务器呢？如何判断我们遇到的性能问题是否与HT有关？是否有某些特定的perfmon计数器组合可能会指向我这个方向,而不是我在改进sql性能时通常会追求的所有其他事情？
编辑：这是特别有吸引力的,因为我的一些高cpu服务器有可能全面改进,但客户端希望看到一些具体的东西,帮助我确定哪些服务器真正可以从禁用超线程中受益.当然,传统的性能故障排除正在进行中,但有时会有所帮助.
解决方法
在sqlOS中,为sql Server看到的每个逻辑处理器创建一个调度程序.启用超线程后,这相当于使调度程序加倍. sqlOS的目的之一是最小化和防止上下文切换的发生,这就是为每个逻辑处理器只创建一个调度程序的原因.一旦sqlOS创建了调度程序,就会在调度程序之间划分工作者总数. sqlOS实现了一种协作调度形式,因为工作者在需要不可用资源时产生调度程序,或者达到其执行量,允许其他工作程序在调度程序上执行.这使得上下文切换保持最小,因为调度程序正在执行工作并且它们是一对一绑定的.
了解背景,超线程有点与sqlOS专门设计的功能相反.具体来说,并行性可能会出现超线程问题,并且可能导致高CXPACKET等待,因为sqlOS可能会尝试在DOP 8上运行DOP 4系统的现实查询.如果您的cpu利用率很低,您可能不会注意到,但cpu利用率越高,问题就越多.我最近在Twitter上就此进行了讨论,并且就它是否会有所帮助或受到伤害而达成的共识是“它取决于”.
如果您的服务器上有很多信号等待,但cpu利用率很低,您可能会看到启用超线程的好处,这会使内部调度程序翻倍并将工作人员分散开来,这意味着他们不会等待在可运行队列中执行只要.但是,如果您的工作负载大量使用并行性,那么在sys.dm_os_wait_stats中会遇到大量的CXPACKET等待,您可能会考虑禁用超线程以查看它是否会减少等待时间.
