CPU时钟速度与CPU核心数量之间的关系-更高的GHz，还是SQL Server使用更多的核心？

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

我们计划设置6个节点，但是关于在CPU时钟速度与CPU核心数之间提供物理服务器的理想方式尚有争议。

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

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

有谁遇到过进一步研究此类主题的白皮书？

一般的经验法则是保持内核数量尽可能少，处理器速度尽可能高。事实证明，昂贵版的许可核心价格约为每核$ 7,500 USD。

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

一旦考虑了SQL Server的每核许可结构，就始终选择可用的最快处理器速度是有意义的，而不管工作负载类型是OLTP还是分析。拥有最快的核心速度永远不会成为问题。根据需要增加核心数量，但绝对不要通过降低核心速度来实现。

换句话说，不要认为16 x 2.2Ghz处理器与8 x 4.5Ghz处理器相同。使用2.2Ghz处理器而不是4.5Ghz处理器最多可节省大约10,000美元（对于典型的基于Xeon的两处理器计算机）。使用SQL Server Enterprise Edition从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)

真可惜，因为当核心数增加时，时钟速度通常会下降一到两代。

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

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

这将在很大程度上取决于：

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

如果您今天还没有耗尽它们，那可能还可以。

但是你怎么知道你是否呢？

有个好问题，有个好问题，lemme告诉您一些重要的问题。

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

您还可以使用免费工具（例如sp_Blitz或sp_BlitzFirst）查看服务器的等待状态（完整披露，我对这个项目有所贡献）。

EXEC sp_Blitz

EXEC sp_BlitzFirst @SinceStartup = 1

我不能只增加Max Worker Threads吗？

MWT的增加可能会导致MWT的增加 SOS_SCHEDULER_YIELD会等待。

那不是世界的尽头，但是可以把它想像成是在老师的课堂上增加一群尖叫的孩子。

突然之间，每个孩子变得难以集中注意力。

当进程耗尽其4ms量子，可能有更多线程在等待CPU。

性能可能大致相同。

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

你[名词]的残酷，那些是有家人支持的工人！抵押！梦想！

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

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

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

• SQL Server的MAXDOP设置算法

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

在那之后，您的工作变得更加艰巨。您必须弄清楚所有这些线程在使用什么。有时您可以通过查看等待状态来做到这一点。

更具体地说，如果您对并行性（CXPACKET）的等待很高（）和对锁（LCK_）的等待很高，那么您可能会遇到涉及并行查询的冗长的阻塞链。

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

您几乎可以听到管理员确定的四个核心VM足以应付任何工作负载，对吧？

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

希望这可以帮助！

_{社区Wiki答案：}

总而言之，它是：SQL Server的大多数工作负载都是OLTP，由于它是串行操作，因此可以从更高的时钟速度中受益。

除非您专门为大型并行系统设计，否则时钟速度将永远胜出。存在边际案例，但这是95％的时间。它最终花费更少的事实也是一件好事。

答案归结为：这取决于您的用例。

• 您是一次处理多个小请求还是几个大请求？
• 您运行的程序是否针对多核进行了优化？

例如，我有一台四核计算机，但ESP8266编译器仅使用我CPU的25％，因为它仅设计为使用一个核。如果我有1个快速核心，那将是最佳选择。