VMware VROOM！博客

来自VMware的绩效团队

帖子导航

←使用Nvidia GPU在vSphere 6上进行机器学习–第2集通过SSD数据存储的存储I / O控制（SIOC）的性能– vSphere 6.5 →

虚拟机vCPU和vNUMA调整大小-经验法则

[2019年7月18日更新–在仅考虑vNUMA计算的示例中进行了更正]

[2017年10月20日更新–具有内存注意事项的“新”]

使用虚拟化，我们所有人都享有灵活性，可以快速创建具有各种虚拟CPU（vCPU）配置的虚拟机，以应对各种工作负载。但是，当我们在具有多达24个内核的最新一代处理器之上虚拟化更大和更苛刻的工作负载（如数据库）时，必须特别注意vCPU和vNUMA配置，以确保性能得到优化。

关于如何在虚拟机中最佳配置vCPU表示，已经有很多说法和文章了-套接字x每个套接字的核心数

侧边栏：创建新的虚拟机时，分配的vCPU数量除以每个插槽的核心数（默认值= 1，除非更改下拉列表），以提供计算出的插槽数。如果使用的是PowerCLI，则这些属性称为NumCPU和NumCoresPerSocket。在上面的示例屏幕截图中，将20个vCPU（NumCPU）除以每个插槽10个内核（NumCoresPerSocket）得出2个插槽。让我们将此虚拟配置称为2个插槽x每个插槽10个内核。

历史

设置此演示文稿的功能最初是在vSphere 4.1中引入的，旨在克服操作系统许可证的限制。从vSphere 5开始，这些配置项现在可以设置暴露给客户机操作系统的虚拟NUMA（vNUMA）拓扑。

NUMA对于确保工作负载（如数据库）在已调度vCPU的同一物理NUMA节点内分配和消耗内存变得越来越重要。当虚拟机的大小大于单个物理NUMA节点的大小时，将创建vNUMA拓扑并将其呈现给来宾操作系统。这种虚拟结构允许虚拟机中的工作负载受益于物理NUMA，同时继续支持vMotion等功能。

尽管vSphere平台具有极高的可配置性，但这种灵活性有时会成为我们最大的敌人，因为它允许许多次优的配置。

早在2013年，我就发表了一篇文章，内容基于vNUMA的配置方式，介绍了每个插槽的内核数如何影响性能。在那篇文章中，我提出了不同的选择，以确保虚拟机的vNUMA演示是正确和最佳的。实现此目的的最简单方法是将每个套接字的内核数保留为默认值1，该值将vCPU计数显示为套接字，而无需配置任何虚拟内核。使用此配置，ESXi将自动生成最佳vNUMA拓扑并将其呈现给虚拟机。

但是，该建议存在一些缺点。由于vCPU仅作为套接字显示，因此Microsoft操作系统和应用程序的许可模型可能会受到套接字数量的限制。今天，基于操作系统内核的许可已不再是一个问题，Microsoft已将其转换为从Windows Server 2016开始，但仍是较早版本的考虑因素。

例：

由于Windows Server 2012和2016最多仅支持64个套接字，因此创建具有64个以上vCPU的“怪兽” Windows虚拟机需要我们增加每个套接字的核心数，以便来宾可以使用所有分配的处理器。

例：

承载单个Microsoft SQL Server 2016 Standard Edition许可证的，具有8个插槽x每个插槽1个核心的虚拟机将只能使用8个vCPU中的4个，因为该版本的许可证限制为“少于4个插槽或24个核心”。如果虚拟机配置了1个插槽x每个插槽8个核心，则可以利用所有8个vCPU（参考：https : //msdn.microsoft.com/zh-cn/library/ms143760.aspx）。

此外，某些应用程序（例如Microsoft SQL Server 2016）会根据呈现给它们的“每个套接字的核心数”拓扑而有所不同。

例：

托管Microsoft SQL Server 2016企业版许可证的虚拟机使用8个插槽x每个插槽2个内核创建，即使它们都是16个vCPU，其行为也可能与使用2个插槽x 8个内核每个插槽创建的虚拟机有所不同。这是由于SQL Server中的软NUMA功能会根据操作系统可以使用的内核数自动进行配置（参考：https : //msdn.microsoft.com/zh-cn/library/ms345357.aspx）。

vSphere 6.5中的vNUMA行为更改

为了自动化和简化配置以获得最佳性能，vSphere 6.5对vNUMA行为进行了一些更改。感谢Frank Denneman在这里完整地记录了它们：

http://frankdenneman.nl/2016/12/12/decoupling-cores-per-socket-virtual-numa-topology-vsphere-6-5/

本质上，vSphere 6.5下的vNUMA表示不再受“每个套接字的核心数”值控制。现在，除非您使用高级设置，否则 vSphere将始终提供最佳的vNUMA拓扑。

那说...

vNUMA仅考虑计算

计算vNUMA拓扑时，它仅考虑计算维度。它不考虑配置给虚拟机的内存量，也没有考虑计算拓扑时每个pNUMA节点内的可用内存量。因此，这需要手动解决。

例：

ESXi主机具有2个pSocket，每个插槽具有10个内核，每个pNUMA节点具有128GB RAM，每个主机总计256GB。

如果您创建的虚拟机具有128GB的RAM和1个插槽x每个插槽10个内核，则vSphere将创建一个vNUMA节点。该虚拟机将适合单个pNUMA节点。

如果您创建的虚拟机具有192GB RAM和每个插槽1个Socket x 10个内核，即使虚拟机的要求将跨越2个pNUMA节点，从而导致远程内存访问，vSphere仍将仅创建一个vNUMA节点。这是因为仅考虑了计算维度。

该虚拟机的最佳配置是2个插槽x每个插槽5个内核，vSphere将为其创建2个vNUMA节点，并为每个节点分配96GB的RAM。

那么我们如何使它变得更容易呢？

根据计算配置可以提供的值，可以遵循以下一些简单规则以确保实现最佳配置。

我提出以下经验法则：

尽管有许多高级vNUMA设置，但只有在极少数情况下才需要将其更改为默认值。
始终将虚拟机vCPU数量配置为反映为“每个套接字的核心数”，直到您超过单个物理NUMA节点的物理核心数量，或者直到您超过单个物理NUMA节点上的可用内存总量。
当您需要配置的vCPU数量超过NUMA节点中的物理核心数量时，或者如果分配的内存量超过NUMA节点包含的内存数量，则将vCPU数量平均分配给最小数量的NUMA节点。
当虚拟机的大小（由vCPU计数或配置的内存衡量）超过物理NUMA节点时，请勿分配奇数个vCPU。
不要启用vCPU热添加，除非您对禁用vNUMA感到满意。
创建的VM不得超过主机的物理核心总数。

例：

下表概述了如何在双插槽10核心物理主机上配置虚拟机，以确保最佳vNUMA拓扑和性能，而不管所分配的内存小于或等于pNUMA节点的vSphere版本如何。

例：

下表概述了如何在双插槽10核心物理主机上配置虚拟机，以确保最佳vNUMA拓扑和性能，而不管所分配的内存大于pNUMA节点的vSphere版本如何。

总结起来，以下是使用这些经验法则提供的一些好处：

无论使用什么版本的vSphere，生成的vNUMA拓扑都是正确且最佳的。
由于虚拟机将包含在最少数量的物理NUMA节点中，因此减少了远程内存访问。
与大多数操作系统和应用程序许可证模型正确匹配。
为来宾内应用程序提供最佳自我配置的机会。

“经验法则”总是有例外，因此让我们在下面的评论部分中进行探索。

@vmMarkA