最近，我们将 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_type 等待任务数 等待时间毫秒 最大等待时间毫秒 信号等待时间毫秒 ------------------------------------------------------------ -------------------- -------------------- -------------------- XE_TIMER_事件 115166 2799125790 30165 2799125065 请求死锁搜索 559393 2799053973 5180 2799053973 SOS_SCHEDULER_YIELD 152289883 189948844 960 189756877 CXPACKET 234638389 2383701040 141334 118796827 睡眠任务 170743505 1525669557 1406 76485386 闩锁_EX 97301008 810738519 1107 55093884 日志管理队列 16525384 2798527632 20751319 4083713 写日志 16850119 18328365 1193 2367880 页锁定_EX 13254618 8524515 11263 1670113 异步网络输入输出 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 等待时间百分比 运行百分比 CXPACKET 554821.66 65.82 65.82 闩锁_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
我仍然觉得测试您的特定工作负载，按照原始答案，是唯一可以确定的方法。当您尝试调整生产系统时，这不是一个理想的答案（因此我想问是否有可能在性能和可用性都很重要的系统中获得相同的测试平台），但这是我唯一真正感到满意的答案。
我们可以讨论超线程是否应该损害或改善一般情况的理论（我发现它对服务器造成的损害比帮助更大，因此对于“通用”部署，我可能会禁用它），但只有一种方法可以确定它是否会对你的具体情况产生影响，那就是尝试一下看看。
答案2
我同意
- 在最好的建议是“在您的工作量上尝试超线程，看看会发生什么”。我现在正在这样做，而且... 效果不好！
- 你应该总是从禁用超线程开始，因为这是最安全的
看起来我们应该调整两件事：
MAXDOP（最大并行度）。我读到的所有内容都表明，不设限可能不是一个好主意，Microsoft 文档说：
将此选项 [MAXDOP] 设置为更大的值 [大于 8] 通常会导致不必要的资源消耗和性能下降。
一般不建议高于这个值
8。所以我暂时将其设置为4。最初为零（无界）。5并行性的成本阈值。显然，根据我发现的一些 SQL MVP 帖子，这里的默认值被认为是一个相当低的默认值——我们可以调整一下减少调度程序尝试的并行程度。
但老实说，这些感觉像是变通方法；我认为对于我们的工作量（全文索引繁重）来说，真正的解决方案是禁用 HT。
答案3
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 芯片。
答案4
根据我的经验，HT 使 Windows 2008 R2 群集（运行 SQL Server 2008 R2）上的活动节点上的 I/O 操作耗时太久。有趣的是，它既没有反映在等待统计数据中，也没有反映在我为 Microsoft 支持运行的 pssdiag 中。
我注意到 I/O 低的方法就是观察物理磁盘的操作系统计数器。正如 Sam 指出的那样，我写了一篇文章这里和这里
如果你没有遇到 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% 降至几乎为零。
祝你好运，如果你找到了解决办法，请随时给我留言，因为我想将该案例添加到我的博客中。
谢谢
奥斯卡