HQY

×

VMware vSphere 故障排查实战系列-VM 性能慢?CPU Ready / Co-Stop 完整排查

hqy hqy 发表于2026-04-30 10:15:33 浏览6 评论0

抢沙发发表评论

VM 性能慢?CPU Ready / Co-Stop 完整排查

VMware vSphere 故障排查实战系列 #3

用户反馈"VM 卡",这句话信息量约等于零。打开 vCenter 一看 Guest CPU 15%,内存 40%,好像没问题。但真实情况可能是:VM 在排队等 CPU。这就是 CPU Ready 和 Co-Stop,它们是诊断"明明资源够却慢"的第一切入点。

一、前置:VM 的 CPU 不是它以为的那样

Guest OS 看到的 CPU 使用率,是它"在 CPU 上跑的时间 / 总时间"。但在虚拟化环境:

  • Guest 不在 CPU 上时

    ,可能是真的空闲,也可能是想跑但 Hypervisor 没给
  • Hypervisor 才是真正的调度者

关键指标(在 ESXi / vCenter 可见,Guest OS 里看不到):

指标
含义
%USED
VM 实际占用物理 CPU 时间
%RDY (Ready)
VM 想跑但 CPU 不可用,在排队
%CSTP (Co-Stop)
多 vCPU VM,部分 vCPU 等待兄弟们同步
%MLMTD
被 CPU Limit 限制的时间
%SWPWT
等内存 swap

性能问题诊断顺序：%RDY → %CSTP → %MLMTD → %USED

二、CPU Ready 详解

2.1 概念

%RDY = VM 想运行但没拿到 CPU 的时间占比。本质是排队等待。

健康阈值(经验值):

  • 单 vCPU VM：

    %RDY < 5% 正常,> 10% 性能受影响

  • 多 vCPU VM：

    需按每 vCPU 分摊看

  • 持续 > 5% 持续超过 10 分钟

     = 值得介入

2.2 怎么查

方法 1:esxtop(ESXi shell,最权威)


ssh root@esxi01
esxtop

# 按 c 进 CPU 视图
# 按 V 只显示 VM
# 按 f 自定义列,加 %RDY, %CSTP, %MLMTD

重要提示:esxtop 显示的 %RDY 是 per-vCPU 的总和。一个 4 vCPU VM 显示 %RDY = 40% 意味着平均每核 10%,而不是 10% 本身 = 正常。

要看按 每 vCPU 平均：%RDY / vCPU 数。

方法 2:vSphere Client 性能图表

VM → Monitor → Performance → Advanced → CPU → Readiness(百分比,已按 vCPU 数归一化,直接看)

方法 3:PowerCLI


$vm = Get-VM "YourVM"
$stat = Get-Stat -Entity $vm -Stat "cpu.ready.summation" `
    -Realtime -MaxSamples 20
# 单位是 ms / 20000ms (20s 采样窗口)
# 换算:%RDY = (ready_ms / (20000 * vCPU数)) * 100

2.3 %RDY 高的根因

原因 A:物理主机 CPU 超卖严重

  • 主机 20 物理核,跑着总计 80 vCPU 的 VM
  • 高峰时刻大家都抢 CPU

验证：


esxtop → 按 c → PCPU USED %
# 如果整体 > 80% 持续,说明主机本身饱和

原因 B:VM vCPU 给太多

vCPU 不是越多越好。多 vCPU VM 需要多个物理核同时空闲才能调度(见 Co-Stop 部分)。

验证：看那个高 %RDY 的 VM 实际业务用几个核。8 vCPU 的 VM 平时只用 2 个 → 改成 2 vCPU,%RDY 往往大幅下降。

原因 C:CPU Limit / Shares 设置不合理

VM 配置了 CPU Limit(MHz),导致达到上限后被压制。

验证：


vSphere Client → VM → Edit Settings → CPU → Limit
# 或 esxtop 里看 %MLMTD

一般不要设 Limit,除非你明确知道为什么。

原因 D:DRS 不均衡

集群里有个主机特别挤,DRS 没把 VM 迁走。

验证：


Get-VMHost | Select Name,
    @{N='CPU%';E={[math]::Round(($_.CpuUsageMhz/$_.CpuTotalMhz)*100,1)}},
    @{N='VMs';E={(Get-VM -Location $_).Count}}

三、Co-Stop 详解(多 vCPU VM 必看)

3.1 概念

多 vCPU VM 需要协同调度：所有 vCPU 的运行进度不能差太远,否则 Guest OS 内的自旋锁、时钟同步会崩。

ESXi 用 Relaxed Co-Scheduling：允许 vCPU 之间有进度差,差超过阈值(通常 ~3ms)就强制停下来等(co-stop)。

反直觉结果：vCPU 越多,调度越难,co-stop 越容易出现。

3.2 典型场景

  • 一个 VM 配 16 vCPU
  • 平时业务只用 2-3 个核
  • 但要调度时必须找 16 个物理核同时空闲
  • 主机上有很多其他 VM → 很难凑齐 → co-stop 升高

  • 结果：

    这个 16 vCPU 的 VM 比 4 vCPU 的更慢

3.3 怎么查

esxtop：


c 视图 → %CSTP
# > 3% 开始值得关注
# > 5% 性能明显受损

vSphere Client：VM → Performance → Advanced → CPU → Co-Stop (ms)

3.4 如何解决

核心解法:降 vCPU 数

  • 先用 Guest OS 内监控(Perfmon / top)看业务峰值实际用几个核
  • 关机 → 改 vCPU → 开机观察
  • 通常从 8/16 vCPU 降到 4 vCPU,性能反而提升

这是反直觉的,但数据和官方文档都支持:按需分配 vCPU,不是越大越好。

四、完整排查决策树


用户反馈"VM 卡"
    │
    ▼
看 Guest OS 内 CPU(Perfmon/top)
    │
    ├─ Guest OS 自己 CPU 100% → 是业务问题,优化应用
    │
    └─ Guest OS CPU 不高(< 50%) → 进入虚拟化层排查
            │
            ▼
       esxtop 看 VM
            │
            ├─ %RDY / vCPU > 5%    → CPU 排队,见第二节
            │   │
            │   ├─ 主机 %PCPU > 80% → 主机超卖,迁 VM 或加资源
            │   ├─ 主机不忙        → VM 配 Limit / Shares 不当
            │   └─ 集群不均衡      → 触发 DRS 手动迁移
            │
            ├─ %CSTP > 3%         → Co-Stop,降 vCPU
            │
            ├─ %MLMTD > 0         → 有 CPU Limit,检查配置
            │
            └─ %SWPWT > 0         → 内存问题(下一章)

五、常见误区

误区 1:看 Guest OS 里的 CPU 就够了

Guest OS 的 CPU = 虚拟 CPU 时钟视角,看不到排队等待。必须在 ESXi 层看。

误区 2:给 VM 加 vCPU 一定变快

对 Co-Stop 敏感的业务,加 vCPU 反而变慢。实测前不要先改配置。

误区 3:主机 CPU 30% 就肯定不忙

30% 是平均值。峰值可能瞬间 100%,造成突发 %RDY。要看秒级数据,不是分钟平均。

误区 4:性能问题只看当前时刻

CPU Ready 有累积效应：持续 5% 比瞬间 30% 危害更大。看历史曲线。

六、实战小技巧

6.1 esxtop 批处理模式(导出数据给 Excel)


# 采集 60 个样本,每 2 秒一个
esxtop -b -d 2 -n 60 > /tmp/esxtop.csv
# 下载到本地用 Excel 透视

6.2 PowerCLI 批量找 %RDY 高的 VM


function Get-TopReady {
    param([int]$Top = 10, [int]$Minutes = 30)
    $since = (Get-Date).AddMinutes(-$Minutes)
    Get-VM | Where PowerState -eq "PoweredOn" | ForEach-Object {
        $s = Get-Stat -Entity $_ -Stat "cpu.ready.summation" `
            -Start $since -Realtime -ErrorAction SilentlyContinue
        if ($s) {
            $avg = ($s | Measure-Object -Property Value -Average).Average
            $pct = [math]::Round($avg / (20000 * $_.NumCpu) * 100, 2)
            [PSCustomObject]@{
                VM = $_.Name
                vCPU = $_.NumCpu
                ReadyPct = $pct
                Host = $_.VMHost.Name
            }
        }
    } | Sort-Object ReadyPct -Descending | Select -First $Top
}

6.3 调整 VM vCPU 的流程

  1. Guest OS 内装监控(Perfmon for Windows,sar for Linux),采集 1 周峰值
  2. 记录实际 CPU 使用的 90th/95th 分位
  3. 选 ceil(95th_pct * vCPU / 100) + 1 作为新值
  4. 关机 → 改配置 → 开机
  5. 观察 1 周,看 %RDY / %CSTP 变化

七、架构建议

  • 标准模板：

    4 vCPU 是大多数业务的起点,不要默认 8/16

  • NUMA 对齐：

    单 VM vCPU 不跨 NUMA 节点(比如双路 CPU 每路 16 核,VM 不超过 16 vCPU)

  • CPU Hot Add 谨慎用：

    启用后 NUMA 优化被禁用,可能影响性能

  • 不要设 CPU Limit

    ,除非有明确多租户合规要求

结语

CPU Ready 和 Co-Stop 是虚拟化环境独有的性能指标,传统操作系统监控抓不到。"VM 卡"这三个字的 80% 情况,看 %RDY / %CSTP 就能给出方向。


打赏

本文链接：https://kinber.cn/post/6512.html 转载需授权！

分享到：


推荐本站淘宝优惠价购买喜欢的宝贝:

image.png

 您阅读本篇文章共花了： 

群贤毕至

访客