Server的“总服务器内存”消耗停滞了几个月，64GB+更可用

Answer 1

我敢打赌，您在配置虚拟CPU时，某些CPU节点和/或内存节点处于脱机状态。

下载服务提供商_闪电战 (免责声明:我是该免费开源脚本的作者之一)并运行它：

sp_Blitz @CheckServerInfo = 1;

查找有关CPU和/或内存节点脱机的警告。只看到前4个CPU套接字，您可能已经将VM配置为6个双核CPU。它最终会遇到一个类似于企业的20核限制如何限制您可以看到的内存量的问题。

如果您想在这里共享sp_Blitz的输出，您可以这样运行它以输出到Markdown，然后您可以将它复制/粘贴到您的问题中：

sp_Blitz @OutputType = 'markdown', @CheckServerInfo = 1;

Update 2018/04/16 -确认。您附加了sp_Blitz输出(谢谢！)它确实显示了离线的CPU和内存节点。构建VM的人将其配置为12个单核CPU，因此只看到前4个套接字(核心)以及附加到它们的内存。

要修复它，关闭VM，将其配置为2套接字，6核VM，然后将看到所有内核和内存。这也将减少SOS_SCHEDULER_YIELD的等待--现在，Server正在敲击前4个核，但仅此而已。在此修复之后，它将能够在所有12个核心上工作。

Answer 2

作为布伦特·奥扎尔的行动计划的增编，我想分享一下结果。正如布伦特所指出的，在VMware中，我们错误地将虚拟机配置为12个单核CPU。这导致SQL Server无法访问其余的8个核心，从而导致了我在最初的问题中描述的内存问题。我们昨晚将服务置于维护模式，以便适当地重新配置VM。我们不仅看到内存以正常的方式爬升，而且正如Brent还暗示的那样，等待的数量呈指数级下降，我们的SQL Server的整体性能也急剧上升。vNUMA配置现在是很高兴的小组件，它们正在切割我们的工作负载。

对于那些可能使用VMware vSphere 6.5的用户，完成布伦特描述的操作项的简单步骤如下。

1. 登录到vSphere群集的VMware Web客户端，并浏览到承载Server的虚拟机。您的VM必须脱机，以便调整CPU和内存配置。
2. 在主窗格中，转到Configure > VM hardware，单击右上角的Edit按钮.您将打开一个具有Edit Settings的上下文菜单。下面的图像是不正确的配置，以供参考。注意，我已经将Cores per Socket设置为1。由于的局限性，这是一个错误的配置。

1. 修复方法就像调整Cores per Socket值一样简单。在我们的例子中，我们将它设置为6，这样就有了2 Sockets。这允许Server利用所有12个处理器。

一个重要的注意事项:不要将Number of Cores或Sockets的值设置为奇数。NUMA喜欢平衡，根据经验法则，需要被2整除。例如，一个由4个核心到3个插座的配置就会不平衡。实际上，如果您要使用这种配置运行sp_Blitz，它会对此发出警告。

在VMware vSphere上架构微软中的3.3节(PDF警告)详细地概述了这一点。白皮书中概述的实践适用于SQL Server的大多数前提下虚拟化。

以下是我在Brent发表文章后通过我的研究汇编的更多资源：

• VMware CPU虚拟化大型数据库容量规划
• 虚拟机vCPU和vNUMA适配.经验规则
• vSphere 6.5中每个套接字核心与虚拟NUMA拓扑的解耦

最后，我将在过去24小时内从RedGate获取信息。首先要注意的是CPU利用率和等待次数--在我们昨天的高峰时段，我们经历了大量的CPU使用和等待竞争。经过这个简单的修复，我们的性能提高了十倍。甚至我们的磁盘I/O也大大减少了。这似乎是一个容易被忽视的设置，可以提高一个数量级的虚拟性能。至少，我们的工程师忽略了这一点，这是一个完整的时刻。

Answer 3

此外，根据MSDN，Server标准仅限于64 to内存。我们通过将数据库拆分成多个实例来“解决”这个问题，但是您的情况可能不允许这样做。

Hmm 2016似乎有128 to的限制，但实例分割可能仍然是一种选择。