虚拟机CPU Co‑Stop高故障排查与调优实战

业务虚拟机操作系统卡顿、应用响应慢，查看esxtop发现虚拟机Co‑Stop数值居高不下，但是虚拟机内部CPU使用率并不高。很多人会误以为是主机CPU算力不足，盲目增加vCPU，结果Co‑Stop反而更高。Co‑Stop代表虚拟CPU之间等待调度的时间，属于vSphere经典调度问题。本文讲解Co‑Stop指标含义、产生根源、排查方法和整套生产调优方案。

有VMware全系列产品官方资源和定制版资源需求的可以移步：

VMware全系列产品官方镜像和定制版下载汇总(更新到2026年8月）

时间：2026-08-01

查看

📋 故障现象复现

1、虚拟机内部系统CPU利用率不高，但业务明显卡顿、延迟大。

2、打开esxtop，切换虚拟机视图，%Co‑Stop指标持续大于5%，严重时超过20%。

3、给虚拟机增加更多vCPU之后，卡顿现象没有好转，Co‑Stop进一步升高。

4、ESXi物理主机CPU整体负载不高，%Ready也不一定很高，但业务体验很差。

🔍 Co‑Stop底层原理解析

Co‑Stop（协同停止时间）：一台虚拟机配置多颗vCPU时，ESXi调度器需要同时为该虚拟机所有vCPU分配物理CPU核心。部分vCPU已经调度到物理核心，其余vCPU还在排队等待，已经拿到时间片的vCPU必须暂停等待其余vCPU，这段等待耗时就是Co‑Stop。

简单理解：多vCPU虚拟机，必须凑齐所有vCPU的物理核心才能一起运行。vCPU数量越多，调度器凑齐一组空闲物理核的难度就越大，Co‑Stop就容易走高。

经验阈值：%Co‑Stop持续大于5%就会对业务产生负面影响；超过10%属于严重调度问题，需要立刻介入调优。

✅ 方案一：减少虚拟机vCPU数量（首选优化手段）

很多虚拟机上线时直接分配大量vCPU，实际业务根本用不到。vCPU数量越大，Co‑Stop调度压力呈上升趋势。

优先分析虚拟机内部真实CPU负载，业务平均负载只有2‑4核，却配置16vCPU，会造成严重的协同等待。

操作建议：关闭虚拟机，降低vCPU数量，只分配业务真实需要的vCPU。不要按照物理机配置习惯给虚拟机配置vCPU，虚拟化环境讲究按需分配。

✅ 方案二：配置CPU预留，保障虚拟机调度资源

核心业务无法减少vCPU数量时，可以配置CPU预留(Reservation)。CPU预留代表ESXi必须为该虚拟机保证对应数量的物理CPU资源，调度器更容易一次性拿到足够物理核心，降低Co‑Stop。

编辑虚拟机设置‑资源‑CPU，设置CPU预留，预留值尽量等于vCPU数量×单核心频率。

注意：CPU预留会锁定主机物理资源，预留之后这部分CPU无法分配给其他虚拟机。预留设置过高，会造成集群资源浪费，甚至DRS无法放置虚拟机，谨慎使用。优先缩减vCPU，预留作为辅助手段。

✅ 方案三：调整虚拟机CPU亲和性，缓解调度竞争

CPU亲和性可以把虚拟机vCPU绑定到特定物理CPU插槽的核心，减少跨NUMA节点调度带来的开销。

但亲和性不建议随便配置，配置错误会限制调度器灵活性，反而加剧性能问题，只适合特定排查场景。DRS集群环境尽量避免长期使用CPU亲和。

✅ 方案四：主机层面优化，缓解整体调度压力

1、单台ESXi主机不要高密度部署大量大vCPU虚拟机。大量多vCPU虚拟机同时运行，调度器压力暴涨，全体虚拟机Co‑Stop集体升高。

2、开启NUMA感知调度，vSphere默认开启，不要手动关闭NUMA。大vCPU虚拟机尽量保证vCPU不跨物理NUMA节点。

3、如果主机CPU负载已经偏高，考虑虚拟机迁移到负载更低的ESXi主机，降低主机整体调度压力。

🔎 实操排查命令，确认Co‑Stop问题

#进入esxtop，按v切换到虚拟机视图，观察%Co‑Stop字段
esxtop

#也可以通过vsish查看指定虚拟机调度指标
vsish -e get /vim/vms/[虚拟机ID]/schedStats

重点区分指标：%Ready是虚拟机等待物理CPU时间；%Co‑Stop是多vCPU之间互相等待协同调度时间，两者含义不一样，很多运维容易混淆。

📊 故障场景对照表

⚠️ 高频踩坑误区汇总

1、Co‑Stop高，盲目增加vCPU。增加vCPU只会让协同调度更难，Co‑Stop会进一步恶化，这是最高频错误。
2、把Co‑Stop和CPU Ready混为一谈。Ready是抢不到物理CPU；Co‑Stop是多颗vCPU之间互相等待，优化思路不一样。
3、优先上来就配置大数值CPU预留。预留会锁定物理资源，造成集群资源碎片化，优先做vCPU裁剪。
4、虚拟机热修改vCPU，部分操作系统热插拔CPU后，系统内部调度依旧异常，建议停机调整vCPU。

❓FAQ常见问题

Q：Co‑Stop低于多少算正常？
A：理想状态维持在1‑3%以内；持续稳定超过5%就需要关注；大于10%会明显感知业务卡顿。

Q：单vCPU虚拟机，会出现Co‑Stop高吗？
A：不会。Co‑Stop是多vCPU协同等待指标，单vCPU虚拟机Co‑Stop永远为0。遇到Co‑Stop高的虚拟机，优先审视vCPU配置是否过大。

Q：开启CPU预留之后，DRS不做虚拟机迁移了？
A：CPU预留会作为DRS放置计算条件，如果目标主机没有足够空闲CPU满足预留，DRS不会把虚拟机调度过去，预留设置过大直接降低集群调度灵活性。

总结：虚拟机CPU Co‑Stop高，核心根源大多是vCPU配置过量。优先评估业务真实负载，减少不必要的vCPU；业务确实需要多核无法缩减，再配置适度CPU预留。不建议盲目调大vCPU，也不要滥用CPU预留。区分Co‑Stop与CPU Ready两个指标，对症下药完成虚拟化调度调优。