如果您基于VMware vSphere（或任何其他技术堆栈）管理虚拟基础架构，则可能经常会听到用户的抱怨：“虚拟机速度很慢！”。 在本系列文章中，我将分析性能指标，并解释什么以及为什么它会“降低”，以及如何确保它不会“降低”。
我将考虑虚拟机的以下性能方面：
我将从CPU开始。
为了进行性能分析，我们需要：
- vCenter Performance Counters是可以通过vSphere Client查看其图形的性能计数器。 这些计数器的信息可在任何客户端版本中使用（C＃中的“ thick”客户端，Flex上的Web客户端和HTML5上的Web客户端）。 在这些文章中，我们将使用来自C＃客户端的屏幕截图，只是因为它们看起来更小巧：)
- ESXTOP是从ESXi命令行运行的实用程序。 借助它的帮助，您可以实时获取性能计数器的值，或将这些值在一定时期内上载到.csv文件以进行进一步分析。 接下来，我将向您详细介绍此工具，并提供一些指向文档和相关文章的有用链接。
一点理论
在ESXi中，每个vCPU（虚拟机核心）（VMware术语中的世界）的操作由一个单独的进程负责。 还有一些服务流程，但是从VM性能分析的角度来看，它们并不那么有趣。
ESXi中的进程可以处于以下四种状态之一：
- 运行 -该过程做了一些有用的工作。
- 等待 -进程不做任何工作（空闲）或正在等待输入/输出。
- Costop是多核虚拟机中发生的一种情况。 当虚拟机监控程序CPU调度程序（ESXi CPU Scheduler）无法调度虚拟机的所有活动核心在物理服务器核心上同时运行时，会发生这种情况。 在物理世界中，所有处理器内核并行工作，VM内的来宾OS期望类似的行为，因此管理程序必须降低VM内核的速度，VM内核具有更快完成节拍的能力。 在现代版本的ESXi中，CPU调度程序使用一种称为轻松协同调度的机制：虚拟机管理程序会考虑“最快”和“最慢”虚拟机内核（偏斜）之间的差距；如果差距超过某个阈值，则“快速”内核将进入Costop状态如果VM内核在此状态下花费大量时间，则可能导致性能问题。
- 就绪 -虚拟机管理程序无法为其执行分配资源时，该过程进入此状态。 高就绪值可能会导致VM性能问题。
虚拟机的基本CPU性能计数器
CPU使用率，％。 显示给定时间段内CPU使用率的百分比。
怎么分析？ 如果VM在90％的时间内稳定地使用CPU，或者存在高达100％的峰值，那么我们就有问题了。 问题不仅表现在VM内部应用程序的“缓慢”操作中，还表现在VM在网络上的不可访问性上。 如果监控系统显示虚拟机定期掉线，请注意“ CPU使用率”图中的峰值。
有一个标准的警报，它显示虚拟机的CPU负载：
怎么办 如果CPU使用率持续压倒VM，那么您可以考虑增加vCPU的数量（不幸的是，这并不总是有帮助）或将VM转移到具有更高效处理器的服务器上。
Mhz中的CPU使用率
在以百分比表示的vCenter使用情况图中，您只能看到整个虚拟机，没有单个核心的图表（Esxtop的核心值以％为单位）。 对于每个核心，您可以查看以MHz为单位的使用情况。
怎么分析？ 碰巧，该应用程序并未针对多核体系结构进行优化：它仅100％使用一个内核，其余的则无负载而处于空闲状态。 例如，使用默认备份设置，MS SQL仅在一个内核上启动该过程。 结果，备份速度降低不是因为磁盘速度慢（这是用户最初抱怨的速度），而是因为处理器无法应对。 通过更改参数解决了该问题：备份开始在多个文件中（分别在多个进程中）并行运行。
核负载不均匀的一个例子。还有一种情况（如上图所示），芯子负载不均匀，其中一些具有100％的峰值。 与仅加载一个内核一样，CPU使用率警报将不起作用（在整个VM上），但是会出现性能问题。
怎么办 如果虚拟机中的软件不均匀地加载内核（仅使用一个内核或内核的一部分），则增加内核数量毫无意义。 在这种情况下，最好将VM移到具有更高效处理器的服务器上。
您也可以尝试检查服务器BIOS中的电源设置。 许多管理员在BIOS中打开高性能模式，从而关闭了C状态和P状态的节能技术。 现代的英特尔处理器使用Turbo Boost技术，由于其他内核，该技术增加了单个处理器内核的频率。 但是它仅适用于包含的节能技术。 如果我们关闭它们，则处理器将无法降低未加载内核的功耗。
VMware建议不要关闭服务器上的节能技术，而应选择可最大化管理程序能源管理的模式。 同时，在管理程序的电源设置中，您需要选择“高性能”。
如果基础架构中有单独的VM（或VM内核）需要提高CPU频率，则正确的功耗配置可以显着提高其性能。
CPU就绪（就绪）
如果VM内核（vCPU）处于“就绪”状态，则不会做有用的工作。 当管理程序找不到可分配虚拟机的vCPU进程的可用物理核心时，就会发生这种情况。
怎么分析？ 通常，如果虚拟机核心处于“就绪”状态的时间超过10％，那么您将注意到性能问题。 简而言之，VM等待物理资源可用性的时间超过10％。
在vCenter中，您可以看到与CPU Ready相关的2个计数器：
这两个计数器的值都可以在整个VM上查看，也可以在单个内核上查看。
准备状态立即以百分比显示值，但仅以实时显示（最近一小时的数据，测量间隔为20秒）。 此计数器最好仅用于搜索“紧追”中的问题。
现成的计数器值也可以从历史角度查看。 这对于建立模式和对问题进行更深入的分析很有用。 例如，如果虚拟机在某个特定时间开始出现性能问题，则可以将挂起的CPU就绪值的间隔与运行VM的服务器上的总负载进行比较，并采取措施降低负载（如果DRS无法应对）。
与“就绪”不同，“就绪”不是以百分比显示，而是以毫秒为单位。 这是一个求和类型计数器，即显示在测量期间VM内核处于就绪状态的时间。 您可以通过一个简单的公式将此值转换为百分比：
（CPU就绪总和值/（图表默认更新间隔，以秒为单位* 1000））* 100 = CPU就绪％
例如，对于下图中的VM，整个虚拟机的Ready峰值如下：
在以百分比计算“就绪”值时，应注意两点：
- 整个VM上的Ready值是各个内核上Ready的总和。
- 测量间隔。 对于实时，这是20秒，例如，在每日图表上，它是300秒。
通过主动的故障排除，这些简单的点很容易被遗漏，并且可以将宝贵的时间花费在解决不存在的问题上。
我们根据下图的数据计算就绪。 （324474 /（20 * 1000））* 100 = 1622％对于整个VM。 如果您查看内核，结果将不会那么吓人：1622/64 =每个内核25％。 在这种情况下，检测技巧非常简单：“就绪”值不现实。 但是，如果我们谈论的是具有多个内核的整个VM的10％到20％，则对于每个内核，该值都可以在正常范围内。
怎么办 “就绪”值较高表示服务器没有足够的处理器资源来支持虚拟机的正常运行。 在这种情况下，仅需减少处理器（vCPU：pCPU）上的超额预订。 显然，这可以通过减少现有VM的参数或将一部分VM迁移到其他服务器来实现。
同停
怎么分析？ 此计数器也具有Summation类型，并转换为类似Ready的百分比：
（CPU同步停止求和值/（图表默认更新间隔，以秒为单位* 1000））* 100 = CPU同步停止％
在这里，您还需要注意每个虚拟机的内核数和测量间隔。
在costop状态下，内核不会执行有用的工作。 通过正确选择VM大小和服务器上的正常负载，同步停止计数器应接近零。
在这种情况下，负载显然是异常的:)怎么办 如果多个具有大量内核的VM在同一虚拟机管理程序上运行，并且CPU上存在超额订购，则停止计数器会增加，这将导致这些VM的性能出现问题。
此外，如果在启用了超扩展的情况下将线程用于同一物理服务器核心上一个VM的活动内核，则停止同步将会增加。 例如，如果VM的核心数比其工作所在的服务器上的物理核心数多，或者为VM启用了“ preferHT”设置，则可能会出现这种情况。 您可以
在此处阅读有关此设置的
信息 。
为避免因高停止而导致VM性能出现问题，请根据在此VM上运行的软件制造商的建议以及运行该VM的物理服务器的功能来选择VM大小。
不要保留内核，这不仅会导致VM本身，而且还会导致其服务器邻居的性能问题。
其他有用的CPU指标
运行 -vCPU测量周期处于运行状态的时间（毫秒），即实际执行的有用工作。
空闲 -vCPU测量周期中有多少时间处于非活动状态。 较高的空闲值不是问题，只是vCPU无需执行任何操作。
等待 -vCPU测量周期处于“等待”状态的时间（毫秒）。 由于该计数器包含IDLE，因此较高的Wait值也不表示有问题。 但是，如果处于较高的等待IDLE值较低，则VM正在等待I / O操作完成，这可能表示硬盘或某些虚拟VM设备的性能出现问题。
最大限制 -由于设置的资源限制，vCPU测量时段处于就绪状态的时间（毫秒）。 如果性能莫名其妙地降低，则在VM设置中检查此计数器的值和CPU限制很有用。 VM可能确实具有您不了解的限制。 例如，当VM从设置了CPU限制的模板倾斜时，就会发生这种情况。
交换等待 -测量期间vCPU等待VMkernel交换操作的时间。 如果此计数器的值大于零，则VM肯定存在性能问题。 我们将在有关RAM计数器的文章中进一步讨论SWAP。
ESXTOP
如果vCenter中的性能计数器适合分析历史数据，则最好在ESXTOP中对问题进行在线分析。 在此，所有值均以最终形式显示（无需翻译任何内容），最小测量时间为2秒。
通过“ c”键调用CPU上的ESXTOP屏幕，如下所示：
为方便起见，您可以通过按Shift-V来仅保留虚拟机进程。
要查看单个VM内核的指标，请按“ e”并输入您感兴趣的VM的GID（以下屏幕快照中的30919）：
简要浏览默认情况下显示的列。 可以通过按“ f”添加其他列。
NWLD（世界数） -组中的进程数。 要扩展组并查看每个进程的指标（例如，多核VM的每个核），请按“ e”。 如果一个组有多个进程，则该组的度量值等于各个进程的度量之和。
％USED-服务器的CPU使用一个或一组进程的周期数。
％运行 -在测量期间，过程处于运行状态的时间，即 进行了有益的工作。 它与％USED的不同之处在于，它不考虑超线程，频率缩放和在系统任务上花费的时间（％SYS）。
％SYS-在系统任务上花费的时间，例如：处理中断，输入/输出，网络操作等。如果VM上有很多输入/输出，则该值可能很高。
OVRLP百分比 -运行VM进程的物理核心在其他进程的任务上花费了多少时间。
这些度量标准如下相关：
％已用=％运行+％SYS-％OVRLP。
通常，％USED指标更具参考价值。
％等待 -在测量期间过程处于等待状态的时间。 包括IDLE。
％IDLE-在测量期间，过程处于IDLE状态的时间。
％SWPWT-在测量期间，vCPU等待多长时间使用VMkernel Swap进行操作。
％VMWAIT-在测量期间，vCPU处于事件等待状态（通常是I / O）的时间。 vCenter中没有类似的计数器。 较高的值表示输入/输出到VM的问题。
％等待=％VMWAIT +％空闲+％SWPWT。
如果VM不使用VMkernel Swap，则在分析性能问题时，建议查看％VMWAIT，因为该指标未考虑VM不执行操作的时间（％IDLE）。
％RDY-测量期间过程处于就绪状态的时间。
％CSTP-测量期间过程处于发布状态的时间。
％MLMTD-由于设置的资源限制，vCPU测量期间处于“就绪”状态的时间。
％WAIT +％RDY +％CSTP +％RUN = 100％-VM核心始终处于这四个状态之一。
系统管理程序上的CPU
vCenter中还存在用于虚拟机监控程序的CPU性能计数器，但是它们并不代表任何有趣的东西-仅仅是服务器上所有VM的计数器总和。
查看服务器上CPU的状态最方便的方法是在“摘要”选项卡上：
对于服务器以及虚拟机，有一个标准的警报：
随着服务器CPU负载的增加，在其上运行的VM开始遇到性能问题。
在ESXTOP中，服务器CPU使用率数据显示在屏幕顶部。 除了标准的CPU负载（这对虚拟机管理程序没有帮助）之外，还有三个指标：
核心利用率（％） -加载物理服务器的核心。 此计数器显示内核在测量期间执行工作的时间。
PCPU UTIL（％） -如果启用了超线程，则每个物理核心有两个线程（PCPU）。 该指标显示每个线程完成工作的时间。
PCPU USED（％）与PCPU UTIL（％）相同，但是它考虑了频率缩放（通过降低内核频率来节能或通过Turbo Boost技术提高内核频率）和超线程。
PCPU_USED％= PCPU_UTIL％*有效核心频率/标称核心频率。
在此屏幕截图中，对于某些内核，由于Turbo Boost的运行，由于内核频率高于标称频率，因此USED值大于100％。关于如何考虑超线程的几句话。 如果进程在服务器的物理核心的两个线程上100％的时间运行，而核心以标称频率运行，则：
- 内核的UTIL为100％，
- 两个线程的PCPU UTIL均为100％，
- 两个线程的PCED使用率将为50％。
如果在测量期间两个线程都不能100％地工作，则在这些线程并行工作的时期中，用于内核的USED PCPU被分成两半。
ESXTOP还具有一个屏幕，其中包含CPU服务器的功耗参数。 在这里，您可以查看服务器是否使用节能技术：C状态和P状态。 通过p键调用：
常见的CPU性能问题
最后，我将基于导致CPU VM性能出现问题的典型原因进行讨论，并给出解决这些问题的简短提示：
核心时钟速度不足。 如果无法将虚拟机转移到更高效的内核，则可以尝试更改能源设置以使Turbo Boost更加有效地工作。
VM的大小设置错误（内核太多/太少）。 如果只放置几个内核，则VM CPU上的负载将很高。 如果很多，赶上高止损点。
服务器上CPU的大量超额订购。 如果VM高就绪状态，请减少CPU上的超额订购。
大型VM上的NUMA拓扑错误。 VM看到的NUMA拓扑（vNUMA）必须与NUMA服务器拓扑（pNUMA）匹配。 关于诊断和针对此问题的可能解决方案，例如，写在
《 VMware vSphere 6.5主机资源深度学习》一书中。 如果您不想更深入，并且对VM上安装的OS没有许可限制，请在一个内核上的VM上执行许多虚拟套接字。 您不会损失太多：）
这就是CPU的全部内容。 提出问题。
在下一部分中，我将讨论RAM。