禁用超线程将提高我们SQL Server安装的性能

相关信息：有关SQL Server和超线程的最新知识

最近，我们将Windows 2008 R2数据库服务器从X5470升级到X5560。从理论上讲，两个CPU的性能非常相似，如果有的话X5560的速度会稍快一些。

但是，SQL Server 2008 R2的性能在过去大约一天中一直很差，CPU使用率也很高。

页面的预期寿命非常长，我们几乎为页面带来了100％的高速缓存命中率，因此内存不是问题。

当我跑步时：

SELECT * FROM sys.dm_os_wait_stats 
order by signal_wait_time_ms desc

我有：

wait_typewaiting_tasks_countwait_time_ms max_wait_time_ms signal_wait_time_ms
-------------------------------------------------- ---------- -------------------- -------------------- -------------------- --------------------
XE_TIMER_EVENT 115166 2799125790 30165 2799125065
REQUEST_FOR_DEADLOCK_SEARCH 559393 2799053973 5180 2799053973
SOS_SCHEDULER_YIELD 152289883 189948844 960 189756877
CXPACKET 234638389 2383701040 141334 118796827
SLEEP_TASK 170743505 1525669557 1406 76485386
LATCH_EX 97301008 810738519 1107 55093884
LOGMGR_QUEUE 16525384 2798527632 20751319 4083713
写日志16850119 18328365 1193 2367880
PAGELATCH_EX 13254618 8524515 11263 1670113
ASYNC_NETWORK_IO 23954146 6981220 7110 1475699

（受影响的10行）

我也跑了

-- Isolate top waits for server instance since last restart or statistics clear
WITH Waits AS (
   SELECT 
        wait_type, 
        wait_time_ms / 1000. AS [wait_time_s],
        100. * wait_time_ms / SUM(wait_time_ms) OVER() AS [pct],
        ROW_NUMBER() OVER(ORDER BY wait_time_ms DESC) AS [rn]
FROM sys.dm_os_wait_stats
WHERE wait_type NOT IN ('CLR_SEMAPHORE','LAZYWRITER_SLEEP','RESOURCE_QUEUE',
    'SLEEP_TASK','SLEEP_SYSTEMTASK','SQLTRACE_BUFFER_FLUSH','WAITFOR','LOGMGR_QUEUE',
    'CHECKPOINT_QUEUE','REQUEST_FOR_DEADLOCK_SEARCH','XE_TIMER_EVENT','BROKER_TO_FLUSH',
    'BROKER_TASK_STOP','CLR_MANUAL_EVENT','CLR_AUTO_EVENT','DISPATCHER_QUEUE_SEMAPHORE',
    'FT_IFTS_SCHEDULER_IDLE_WAIT','XE_DISPATCHER_WAIT', 'XE_DISPATCHER_JOIN'))

SELECT W1.wait_type, 
    CAST(W1.wait_time_s AS DECIMAL(12, 2)) AS wait_time_s,
    CAST(W1.pct AS DECIMAL(12, 2)) AS pct,
    CAST(SUM(W2.pct) AS DECIMAL(12, 2)) AS running_pct
FROM Waits AS W1
INNER JOIN Waits AS W2 ON W2.rn <= W1.rn
GROUP BY W1.rn, W1.wait_type, W1.wait_time_s, W1.pct
HAVING SUM(W2.pct) - W1.pct < 95; -- percentage threshold

并得到

wait_type wait_time_s pct running_pct
CXPACKET 554821.66 65.82 65.82
LATCH_EX 184123.16 21.84 87.66
SOS_SCHEDULER_YIELD 37541.17 4.45 92.11
PAGEIOLATCH_SH 19018.53 2.26 94.37
FT_IFTSHC_MUTEX 14306.05 1.70 96.07

这表明大量时间同步涉及并行性的查询（高CXPACKET）。此外，许多问题查询都在多个内核上执行（我们的代码中任何地方都没有MAXDOP提示）

服务器没有超过一天左右的负载。我们在查询执行方面遇到了很大的差异，通常许多查询似乎比我们以前的数据库服务器上的查询慢，并且CPU确实很高。

禁用超线程是否有助于减少CPU使用率并提高吞吐量？

我仍然认为，按照原始答案测试您的特定工作负载是唯一可以确定的方法。当您尝试调整生产系统时，这不是一个理想的答案（因此，我想问一问，是否有可能在性能和可用性都至关重要的系统中获得相同的测试平台），但这是我真正感到满意的唯一答案用。

我们可以讨论一下一般而言超线程是否应该损害或改善事物的理论（我发现它比服务器上的帮助更容易受到损害，因此对于“通用”部署，我可能会禁用它），但是有只有一种方法可以确定在特定情况下是否会有所作为，那就是尝试一下。

我同意

• 在最好的建议是“在你的工作量尝试超线程，看看会发生什么。” 我正在打字时正在执行此操作，..这不好！
• 您应该始终从禁用超线程开始，因为这是最安全的

看来我们应该调整两件事：

1. MAXDOP（最大并行度）。我读到的所有内容都表明，无限制的访问可能不是一个好主意，因此Microsoft文档说：

   将此选项[MAXDOP]设置为较大的值[大于8]通常会导致不必要的资源消耗和性能下降。

   比8一般不建议的任何高..所以我暂时将其设置4为。最初为零（无界）。

2. 并行成本阈值。5根据我发现的一些SQL MVP帖子，显然这里的默认值被认为是相当低的默认值-我们可以对其进行优化以减少调度程序甚至尝试了多少并行性。

但说实话，这些感觉都是解决方法；我认为针对我们的工作量（全文索引繁重）的真正解决方案是禁用HT。

Anandtech发现，在纯读取负载的情况下，它会受到一点伤害；在写入重负载的情况下，这是一个胜利。我没有看到任何让我认为这会让您的命中率远低于-5％或赢得远胜于15％的东西。请注意，使用Atom可以取得巨大的成功，但这是非常奇怪的CPU。

您更改的只是CPU？您从12MB高速缓存和4个线程（即每个线程3MB高速缓存）变为8 MB高速缓存和8个线程（即每个线程1MB）。现在，这太过简单了，但是我敢打赌，这就是杀死您的原因，您曾经在高速缓存中运行查询，现在从RAM运行查询，因为它们需要大于1MB但小于3MB的内存。关闭HT可能会有所帮助，但我会回到旧的CPU。关闭HT，每个线程可获得2MB的内存，但是如果您的工作量如此之大，将无济于事。很可能旧的12MB缓存cpu可以大大加快您的工作量。

我会尝试关闭HT，看看是否有改善，但是我怀疑高速缓存是您工作量的重中之重，您很可能需要回到12 MB芯片。

超线程充其量只是直接从L1和L2缓存直接访问而从操作系统中抽象出任务切换并将其放置在裸片上的一种方法，这使得任务切换的处理速度更快。

使用VMWare进行的测试表明，禁用HT在标准负载下没有明显区别，而在重负载下则增加了5％，这是因为ESXi足够聪明，可以知道“真实”线程和“假”线程之间的区别。 （还有很多其他功能，但这只是外行的说法）。SQL Server 2005并不是很聪明，但是将它与最新的操作系统结合在一起，禁用HT几乎没有优势。

话虽如此，我同意Ronald的观点，这很可能是您的L2缓存。缓存大小减少了33％是相当大的，当我们指定SQL Server时，每次总是以原始时钟速度进行缓存。

根据我的经验，HT使得我在Windows 2008 R2群集（运行SQL Server 2008 R2）上的活动节点上的I / O操作永远无法完成。一个有趣的事实是，它既没有反映在等待统计中，也没有反映在我为获得Microsoft支持而运行的pssdiag中。

我注意到低I / O的方式只是通过查看物理磁盘的OS计数器。正如山姆指出的那样，我在这里和这里都写过

如果您没有遇到I / O问题并且受CPU限制，建议您以这种方式启动：

查明哪些进程和T-SQL块导致最多的CPU使用率。根据我们的经验，在解决了I / O问题（通过关闭HT）之后，我们确定了在2008 R2中表现出色并在2005年表现良好的代码。我在此处进行了介绍。

在高负载下，运行Adam Machanic的sp_whoisactive。您可以从这里下载。由于一个非常糟糕的计划，导致逻辑读取数量过多（每个查询2000万个），因此我们遇到了很高的CPU使用率。我们的流程正在对已分区的表执行反半联接。

我的下一个建议是运行事件探查器，以识别一组CPU和I / O逻辑读取次数都很高的T-SQL代码。

通过上述步骤，我们能够调整有问题的进程，并将CPU持续使用率从85％降至几乎为零。

祝您好运，如果您找到解决方法，请随时给我留言，我想将案例添加到我的博客中。

谢谢

奥斯卡奖

HT的好坏很难确定。

它确实确实取决于基于经验和阅读的服务器负载模式。也就是说，当它影响性能时，它会表现得很糟：否则，您不会注意到它。

我读到的理论是线程共享缓存，这意味着在不利条件下，每个线程都可以覆盖另一个线程的缓存。如果您没有太多的并行性，或者您的负载是许多短查询，那么它可能不会影响您。

我已经尝试过使用MAXDOP和处理器相关性（回到我在SQL Server 2000上的上一个真正的DBA角色），但是找不到任何结论性的东西：但仅限于当时的我的商店。

作为一项快速测试，您可以将处理器亲缘性设置为仅使用物理核心（较低的数字）并查看会发生什么。

但是，您最多损失一半的核心。如今，与几年前我玩的是2 vs 4或4 vs 8相比，这可能并不重要。现在是8 vs 16或16 vs 32。

编辑：Slava Oks的测试

不幸的是，我认为除了“尝试关闭超线程，看看是否有帮助”之外，您没有其他确定的答案。

尽管乔纳森（Jonathan）在我的原始帖子中提供了有用的答案（您在问题中进行了链接），但我始终无法获得任何有关HT对我正在调查的特定服务器的影响的确切证据。就我而言，服务器已经排定了更换时间，因此可以简单地说，让这些更换“解决问题”。

我的建议：

尝试将服务器级别的并行度设置为1。无论如何，SQL上的并行性对于较大的，运行时间较长的查询最有用，而且无论如何，您的负载（我认为）由大量的较小查询组成。这应该完全消除CXPACKET等待。这可能会使某些单个查询的运行时间稍长一些，但应允许服务器上的总查询具有更大的“吞吐量”。

在OLTP服务器上执行此操作取得了良好的效果。其他类型的服务器（报告服务器，处理服务器，数据仓库）肯定需要更高的MAXDOP设置。

需要明确的是，此设置仍将允许SQL对JOIN中的每个表使用多个线程，因此您并没有真正完全消除并行性。

至少值得一试，因为此设置更改会立即生效，甚至不需要您重新启动SQL服务：http : //msdn.microsoft.com/zh-cn/library/ms181007.aspx
这意味着您可以进行切换如果事情开始到地狱，它会立即返回。

关闭BIOS中的超线程将要求服务器完全重新启动，因此风险更高。

记录下来，服务器升级后，我们的性能也出乎意料的糟糕。原来是由于BIOS和CPU节能问题。服务器（HP）的默认设置是忽略操作系统对CPU速度的控制，并使用其自己的算法。将其更改为OS控制，并更新BIOS，将带来重大改进。有一些发行说明（现在找不到它们）表明存在一个BIOS错误，该错误将CPU锁定在最低性能状态。

https://serverfault.com/a/196329/6390