我们开始为 VMware 中的 SQL Server 2016 节点虚拟集群配置一组物理服务器。我们将使用企业版许可证。
我们计划设置 6 个节点，但对于在 CPU 时钟速度与 CPU 核心数方面配置物理服务器的理想方式存在一些争议。
我知道这在很大程度上取决于事务量和存储的数据库数量以及其他特定于软件的因素，但是是否有建议的一般经验法则？
例如，双 8 核 3.2 GHz 物理服务器（16 核）是否比双 16 核 2.6 GHz 服务器（32 核）更优惠？
有没有人遇到过进一步深入研究此类主题的白皮书？
一般的经验法则是保持内核数量尽可能低，处理器速度尽可能高。其许可数学证明了企业版每个内核约 7,500 美元。
购买正确的硬件可以降低许可成本，从而收回成本。请参阅Glenn Berry的 SQL Server 处理器选择。这是关于如何为 SQL Server 选择处理器的绝佳资源。
一旦考虑到 SQL Server 的每核许可结构，无论工作负载类型如何，无论是 OLTP 还是分析，始终采用可用的最快处理器速度是有意义的。拥有尽可能快的核心速度永远不会成为问题。根据需要增加核心数量，但永远不要通过降低核心速度来做到这一点。
换句话说，不要认为 16 x 2.2Ghz 处理器与 8 x 4.4Ghz 处理器相同。使用 2.2Ghz 处理器比使用 4.4Ghz 处理器节省的硬件成本最多可能约为 10,000 美元（对于典型的基于 Xeon 的两处理器机器）。但是，使用 SQL Server 企业版从 8 核升级到 16 核可能需要额外支付 60,000 美元的许可费用。换句话说，您可能会节省 10,000 美元的硬件成本，但您将额外损失 50,000 美元的许可费用。
如果您决定需要大量并行处理能力，并决定手头的任务需要 32 个内核，那么使用最快的内核将在减少处理时间方面带来好处。没有人会因此而责怪你。
说了这么多，如果选择一个 CPU 或多个 CPU，总是选择多个。在单个 CPU 上运行 SQL Server（或任何 DBMS）可能会导致各种问题，因为并发操作的能力非常有限。
等一下 等一下
虽然性能和许可方面很有趣，但它们并不是工作负载需要考虑的唯一方面。
可能对处理器选择产生影响的一件事是工作线程。
工作线程？
是的，伙计！它们是您的 SQL Server 将用来运行您的查询并执行它需要执行的所有后台操作以保持状态的东西。
当您用完工作线程时，您会遇到THREADPOOL等待
线程池？
线程池。这是您在服务器上遇到的最糟糕的等待之一，还有RESOURCE_SEMAPHORE 和 RESOURCE_SEMAPHORE_QUERY_COMPILE。但那些是内存等待，这是一个 CPU 问题。
所以回到为什么这是摇摆不定的怪人。
这是 SQL Server 计算工作线程的方式：
请注意，核心数量加倍不会使最大工作线程数加倍，并且您使用 1 个核心获得的数量与使用 4 个核心获得的数量相同？方程是：
512 + ((logical CPUs - 4) * 16)这是一种耻辱，因为当核心数量增加时，时钟速度通常会下降到一两代。
看看最近的任何英特尔芯片系列都会显示出类似的趋势。
我怎么知道我需要多少线程？
这在很大程度上取决于：
如果你今天没有用完它们，你可能没问题。
但是你怎么知道你是不是？
有很好的问题，也有很好的问题，让我告诉你一些事情，这是一个很好的问题。
THREADPOOL 可能表现为连接问题，您可能会在错误日志中看到有关无法生成线程的消息。
您还可以使用sp_Blitz 或 sp_BlitzFirst等免费工具查看服务器的等待统计信息（完全公开，我为这个项目做出了贡献）。
EXEC sp_BlitzEXEC sp_BlitzFirst @SinceStartup = 1我不能只增加最大工作线程数吗？
增加 MWT 会导致
SOS_SCHEDULER_YIELD等待时间增加。这不是世界末日，但可以把它想象成在老师的课堂上增加一群尖叫的孩子。
突然之间，每个孩子都很难引起注意。
当一个进程耗尽它的 4ms时间片时，可能会有更多的线程在它前面等待上 CPU。
性能可能感觉差不多。
如何使用更少的工作线程？
你个[名词]残忍的[名词]，那些是有家庭养家的工人！抵押贷款！梦想！
但是，好吧，必须尊重底线。你是老板。
最容易开始的地方是更改默认设置，例如 MAXDOP 和 Cost Threshold For Parallelism。
如果您对如何设置有疑问，请前往此处：
SQL Server 的 MAXDOP 设置算法
为什么并行性的成本阈值不应设置为 5
在那之后，你的工作变得更加艰难。你必须弄清楚是什么在使用所有这些线程。您有时可以通过查看等待统计信息来做到这一点。
更具体地说，如果您对并行性 (
CXPACKET) 的高等待和对锁 (LCK_) 的高等待，那么您可能遇到涉及并行查询的长阻塞链。你知道什么臭吗？虽然所有这些并行查询都在等待获得它们的锁，但它们并没有归还分配的线程。
您几乎可以听到您的管理员向您保证的四核虚拟机足以应付任何喘不过气来的工作负载，对吧？
不幸的是，为解决这些问题而必须执行的查询和索引调整类型超出了问题的范围。
希望这可以帮助！
社区维基回答：
总而言之：SQL Server 的大多数工作负载都是 OLTP，它受益于更高的时钟速度，因为它是串行操作。
除非您专门为大规模并行系统设计，否则时钟速度总是会胜出。存在边缘情况，但这是 95% 的时间答案。它最终花费更少的事实也是一件好事。
答案归结为：这取决于您的用例。
例如，我有一台四核计算机，但 ESP8266 编译器只使用了我 25% 的 CPU，因为它只设计为使用一个内核。如果我有 1 个快速核心，那会更理想。