CPU 时钟速度与 CPU 核心数 - 更高的 GHz，还是 SQL Server 的更多核心？

Question

我们开始为 VMware 中的 SQL Server 2016 节点虚拟集群提供一组物理服务器。我们将使用企业版许可证。

我们计划设置 6 个节点，但关于在 CPU 时钟速度与 CPU 核心数方面配置物理服务器的理想方式存在一些争论。

我知道这在很大程度上取决于交易量和存储的数据库数量以及其他特定于软件的因素，但是否有建议的一般经验法则？

例如，双 8 核 3.2 GHz 物理服务器（16 核）是否比双 16 核 2.6 GHz 服务器（32 核）更优惠？

有没有人遇到过进一步深入研究此类主题的白皮书？

Answer 1

一般的经验法则是保持内核数量尽可能少，处理器速度尽可能高。许可数学证明了企业版每核心约 7,500 美元的点。

购买正确的硬件可以通过降低许可成本来收回成本。请参阅Glenn Berry 的SQL Server 处理器选择。这是关于如何为 SQL Server 选择处理器的重要资源。

一旦考虑到 SQL Server 的每核许可结构，无论工作负载类型如何，无论是 OLTP 还是分析，始终使用可用的最快处理器速度是有意义的。拥有尽可能快的核心速度永远不会成为问题。根据需要增加核心数，但切勿通过降低核心速度来这样做。

换句话说，不要认为 16 x 2.2Ghz 处理器与 8 x 4.5Ghz 处理器相同。与 4.5Ghz 处理器相比，使用 2.2Ghz 处理器最多可节省约 10,000 美元（对于典型的基于 Xeon 的两处理器机器）。使用 SQL Server 企业版从 8 核跃升至 16 核可能需要超过 60,000 美元的许可费用。换句话说，您可能会节省 10,000 美元的硬件成本，但您将额外损失 50,000 美元的许可费用。

如果您决定需要大量并行处理能力，并决定手头的任务需要 32 个内核，那么使用最快的内核将在减少处理时间方面带来好处。没有人会因此责怪你。

话虽如此，如果选择是一个 CPU 或多个 CPU，请始终选择多个。在单个 CPU 上运行 SQL Server（或任何 DBMS）可能会导致各种问题，因为并发操作的能力非常有限。

Answer 2

坚持 坚持 坚持

虽然性能和许可方面很有趣，但它们并不是要考虑的工作负载的唯一方面。

可能对处理器选择产生影响的一件事是工作线程。

工作线程？

是的伙计！它们是您的 SQL Server 将用来运行您的查询并执行它需要做的所有后台工作以保持状态的东西。

当您用完工作线程时，您会点击THREADPOOL等待

线程池？

线程池。这是您可以在服务器上进行的最讨厌的等待之一，还有RESOURCE_SEMAPHORE 和 RESOURCE_SEMAPHORE_QUERY_COMPILE。但那些是内存等待，这是一个 CPU 问题。

所以回到为什么这是 wigggity 怪胎。

这是 SQL Server 计算工作线程的方式：

请注意，内核数量加倍并不会使最大工作线程数加倍，并且 1 个内核与 4 个内核获得的数量相同？等式是：512 + ((logical CPUs - 4) * 16)

这是一种耻辱，因为当核心数量增加时，时钟速度通常会下降一两代。

看看最近的任何英特尔芯片系列都会显示出类似的趋势。

我怎么知道我需要多少线程？

这在很大程度上取决于：

• 用户数
• 并行查询数
• 串行查询数
• 数据库数量和数据同步（镜像、AG、日志传送备份）
• 如果您将 MAXDOP 和 CTFP 保留为默认值

如果你今天没有用完它们，你可能没事。

但是你怎么知道你是不是？

有很好的问题，而且有很大的问题，还是让我和告诉你，这是一个很好的问题。

THREADPOOL 可能表现为连接问题，您可能会在错误日志中看到有关无法生成线程的消息。

您还可以使用免费工具（如sp_Blitz 或 sp_BlitzFirst）查看服务器的等待统计信息（完全公开，我为该项目做出了贡献）。

EXEC sp_Blitz

EXEC sp_BlitzFirst @SinceStartup = 1

我不能只增加最大工作线程数吗？

增加 MWT 会导致SOS_SCHEDULER_YIELD等待时间增加。

这不是世界末日，但可以把它想象成在老师的课堂上添加一群尖叫的孩子。

突然之间，每个孩子都更难获得关注。

当一个进程用完它的 4ms时间段时，它前面可能会有更多的线程等待进入 CPU。

性能可能感觉差不多。

如何使用更少的工作线程？

你残忍的[名词]一个[名词]，那些是有家可归的工人！按揭！梦想！

但好吧，必须尊重底线。你是老板。

最简单的开始是更改 MAXDOP 和并行成本阈值等设置的默认值。

如果您对如何设置这些有疑问，请访问此处：

• SQL Server MAXDOP 设置算法

• 为什么并行性的成本阈值不应设置为 5

在那之后，你的工作变得更加艰难。您必须弄清楚所有这些线程的用途。您有时可以通过查看等待统计数据来做到这一点。

更具体地说，如果您对并行性 ( CXPACKET) 的等待时间LCK_很长并且对锁 ( ) 的等待时间很长，那么您可能会遇到涉及并行查询的长阻塞链。

你知道什么臭吗？当所有这些并行查询都在等待获取它们的锁时，它们不会返回分配给它们的线程。

您几乎可以听到您的管理员向您保证的四核 VM 足以应对任何喘不过气来的工作负载，是吗？

不幸的是，为解决这些问题而必须执行的查询和索引调整类型超出了问题的范围。

希望这可以帮助！