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