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

Question

最近，我们将 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

Run Code Online (Sandbox Code Playgroud)

我有：

wait_type waiting_tasks_count wait_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
睡眠任务 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

Run Code Online (Sandbox Code Playgroud)

并得到

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 使用率和增加吞吐量？

Answer 1

Jef*_*ood 12

我同意

在最好的建议是“在你的工作量尝试超线程，看看会发生什么。” 我打字的时候我们正在做这件事，而且……不好！
你应该总是从禁用超线程开始，因为这是最安全的

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

MAXDOP（最大并行度）。我读到的一切都表明，拥有这个无限可能是一个坏主意，微软文档说：

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

任何高于8通常不推荐的东西..所以我4现在将其设置为。它最初为零（无界）。
并行性的成本阈值。显然，5根据我发现的一些 SQL MVP 帖子，这里的默认值被认为是相当低的默认值——我们可以对其进行调整以减少调度程序甚至尝试的并行度。

但老实说，这些感觉像是变通办法；我认为我们工作负载（全文索引繁重）的真正解决方案是禁用 HT。

MAXDOP 也会导致 HT 出现问题，因为它可能会尝试在同一个 CPU 上执行两个线程，如果您说 8 核和 16 个线程，并且您的 maxdop 设置为 10。通常每个逻辑处理器 1 MAXDOP 应该是最大值。在同一个 CPU 上为同一个进程执行两个线程是毫无意义的。 (4认同)
@Farseeker 只有在您没有支持超线程的操作系统时才会发生。比 2000 新的 Windows 知道它。 (2认同)
SQL Server 的标准版本在无限制时无论如何都会在 MAXDOP 为 4 时达到最大值。需要企业达到更高的水平。我们有一些工作负载在 MAXDOP 为 1（非 HT 盒，运行多个 8 核 AMD）时速度最快…… (2认同)

Answer 2

Rob*_*oir 10

我仍然觉得根据原始答案测试您的特定工作量是唯一确定的方法。当您尝试调整生产系统时，这不是一个理想的答案（所以我会问是否有可能在性能和可用性都非常重要的系统中获得相同的测试平台）但它是唯一一个我真的很舒服和。

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

在这里投票 - 我同意答案。一般答案是：关闭超线程。更具体的答案是：这取决于具体情况，必须进行测试。 (5认同)
注意我没有投反对票，我们需要我们可以获得的所有帮助，但是我们希望避免在生产系统的黑暗中刺伤。我想确保在调用此设置之前我们收集了足够的诊断信息。 (3认同)
我相信您确实希望避免“玩弄”生产系统，在理想的世界中，出于这个原因，我们都会拥有与生产系统相同的测试环境。我同意不想改变投机的生产。但是，我坚持我的回答：测试特定的工作负载是*任何部署*的重要组成部分，任何告诉你不同的人都是骗子。对我来说，所有迹象都表明超线程在这里是一个问题，但我们可以整天整夜谈论事情，但仍然只有一种方法可以确定。 (3认同)

Answer 3

Ron*_*tol 9

Anandtech 发现，在纯读取负载下，它会受到一点伤害，而在写入负载较重的情况下，这有点胜利。我没有看到任何让我认为它会让你受到比 -5% 差得多的打击，或者比 15% 好得多的胜利。请注意，对于 Atom，这是一个巨大的胜利，但这是一个非常奇怪的 CPU。

你改变的只是cpu？您从 12MB 缓存和 4 个线程（每个线程 3MB 缓存）变为 8MB 缓存和 8 个线程，每个线程 1MB。现在，这过于简单化了，但我敢打赌，这正是您要死的原因，您曾经在缓存中运行查询，而现在从 RAM 中运行它们，因为它们需要超过 1MB 但不到 3MB。关闭 HT 可能会有所帮助，但我会回到旧 CPU。关闭 HT，您将获得每个线程 2MB 的空间，但如果您的工作负载如此之大，那将无济于事。很可能旧的 12MB 缓存 cpu 对于您的工作负载来说要快得多。

我会尝试关闭 HT，看看这是否有改进，但我怀疑缓存对于您的工作负载很重要，您可能需要回到 12 MB 芯片。

每个核心的 L2 缓存观察是一个*大量*过度简化，因为 CPU 领先整整一代（Nehalem/Core i7 与 Core 2 Quad 类）。 (3认同)

Answer 4

Mar*_*son 7

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

使用 VMWare 进行的测试表明，禁用 HT 在标准负载下没有明显区别，在重负载下增加 5%，因为 ESXi 足够聪明，知道“真实”线程和“假”线程之间的区别（除此之外还有很多，但这是外行人的说法）。SQL Server 2005 并不是那么智能，但它结合了最新的操作系统，禁用 HT 应该没什么好处。

综上所述，我同意 Ronald 的观点，它很可能是您的 L2 缓存。缓存大小减少了 33% 是相当可观的，当我们指定 SQL Server 时，我们总是每次都以超过原始时钟速度的速度进行缓存。

通常，您会设置与其他 CPU 线程的关联，但只要 MAXDOP 设置正确，我认为根本没有理由设置关联。对于 HT，虽然第一个在 CPU 上被命中的线程成为“主”线程，而第二个线程是“HT”线程。虽然没有真正的“主”和“ht”线程，因为它是先到达那里的线程，然后当他们切换任务时，顺序是相反的。 (3认同)

Answer 5

oza*_*ora 7

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

我注意到低 I/O 的方式只是通过观察物理磁盘的操作系统计数器。正如山姆指出的那样，我在这里和这里写过它

如果您没有遇到 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% 持续到几乎为零。

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

谢谢

奥斯卡

归档时间：	15 年前
查看次数：	37881 次
最近记录：	11 年，11 月前