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

#1 楼

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

购买正确的硬件可以降低许可成本，从而收回成本。请参阅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）可能会引起各种问题，因为并发操作的能力受到很大限制。

#2 楼

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

可以影响处理器选择的一件事是工作线程。

工作线程？

是的，伙计！它们是SQL Server用于运行查询并执行所有必要的后台工作以保持状态的东西。

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

THREADPOOL？

THREADPOOL。与RESOURCE_SEMAPHORE和RESOURCE_SEMAPHORE_QUERY_COMPILE一起，这是服务器上最讨厌的等待之一。但这是内存等待，这是CPU问题。

再回到为什么这是摇摆不定的原因。 >请注意，将核心数量加倍不会使“最大辅助线程”数量增加一倍，并且使用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可以导致SOS_SCHEDULER_YIELD等待增加。

这还不是世界的尽头，但是可以把它想像成一堆尖叫着的孩子上老师的课。

突然之间，每个孩子都很难受到关注。

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

性能可能大致相同。

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

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

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

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

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


SQL Server的MAXDOP设置算法
为什么要为并行性设置成本阈值不会设为5

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

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

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

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

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

希望有帮助！

#3 楼

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

除非如果您是为大型并行系统专门设计的，则时钟速度将永远胜出。存在极端情况，但这是95％的时间。最终花费更少的事实也是一件好事。

#4 楼

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


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

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