业务虚拟机操作系统卡顿、应用响应慢查看esxtop发现虚拟机Co‑Stop数值居高不下但是虚拟机内部CPU使用率并不高。很多人会误以为是主机CPU算力不足盲目增加vCPU结果Co‑Stop反而更高。Co‑Stop代表虚拟CPU之间等待调度的时间属于vSphere经典调度问题。本文讲解Co‑Stop指标含义、产生根源、排查方法和整套生产调优方案。 故障现象复现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之间互相等待协同调度时间两者含义不一样很多运维容易混淆。 故障场景对照表现象根因判断处理方案Co‑Stop高虚拟机内部CPU使用率低vCPU配置远高于业务负载vCPU过量分配调度困难关机缩减vCPU数量这是最优方案业务确实需要多vCPU不能减少核数Co‑Stop偏高调度器难以凑齐空闲物理核配置合理CPU预留迁移到负载更低主机集群多台虚拟机全部Co‑Stop上涨主机大量大vCPU虚拟机并发运行降低主机虚拟机密度分散业务到多台ESXiCo‑Stop高同时%Ready也很高主机CPU资源整体吃紧主机扩容CPU或者迁移部分虚拟机⚠️ 高频踩坑误区汇总1、Co‑Stop高盲目增加vCPU。增加vCPU只会让协同调度更难Co‑Stop会进一步恶化这是最高频错误。2、把Co‑Stop和CPU Ready混为一谈。Ready是抢不到物理CPUCo‑Stop是多颗vCPU之间互相等待优化思路不一样。3、优先上来就配置大数值CPU预留。预留会锁定物理资源造成集群资源碎片化优先做vCPU裁剪。4、虚拟机热修改vCPU部分操作系统热插拔CPU后系统内部调度依旧异常建议停机调整vCPU。❓FAQ常见问题QCo‑Stop低于多少算正常A理想状态维持在1‑3%以内持续稳定超过5%就需要关注大于10%会明显感知业务卡顿。Q单vCPU虚拟机会出现Co‑Stop高吗A不会。Co‑Stop是多vCPU协同等待指标单vCPU虚拟机Co‑Stop永远为0。遇到Co‑Stop高的虚拟机优先审视vCPU配置是否过大。Q开启CPU预留之后DRS不做虚拟机迁移了ACPU预留会作为DRS放置计算条件如果目标主机没有足够空闲CPU满足预留DRS不会把虚拟机调度过去预留设置过大直接降低集群调度灵活性。总结虚拟机CPU Co‑Stop高核心根源大多是vCPU配置过量。优先评估业务真实负载减少不必要的vCPU业务确实需要多核无法缩减再配置适度CPU预留。不建议盲目调大vCPU也不要滥用CPU预留。区分Co‑Stop与CPU Ready两个指标对症下药完成虚拟化调度调优。 虚拟机CPU Co‑Stop高故障排查与调优实战
业务虚拟机操作系统卡顿、应用响应慢查看esxtop发现虚拟机Co‑Stop数值居高不下但是虚拟机内部CPU使用率并不高。很多人会误以为是主机CPU算力不足盲目增加vCPU结果Co‑Stop反而更高。Co‑Stop代表虚拟CPU之间等待调度的时间属于vSphere经典调度问题。本文讲解Co‑Stop指标含义、产生根源、排查方法和整套生产调优方案。 故障现象复现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之间互相等待协同调度时间两者含义不一样很多运维容易混淆。 故障场景对照表现象根因判断处理方案Co‑Stop高虚拟机内部CPU使用率低vCPU配置远高于业务负载vCPU过量分配调度困难关机缩减vCPU数量这是最优方案业务确实需要多vCPU不能减少核数Co‑Stop偏高调度器难以凑齐空闲物理核配置合理CPU预留迁移到负载更低主机集群多台虚拟机全部Co‑Stop上涨主机大量大vCPU虚拟机并发运行降低主机虚拟机密度分散业务到多台ESXiCo‑Stop高同时%Ready也很高主机CPU资源整体吃紧主机扩容CPU或者迁移部分虚拟机⚠️ 高频踩坑误区汇总1、Co‑Stop高盲目增加vCPU。增加vCPU只会让协同调度更难Co‑Stop会进一步恶化这是最高频错误。2、把Co‑Stop和CPU Ready混为一谈。Ready是抢不到物理CPUCo‑Stop是多颗vCPU之间互相等待优化思路不一样。3、优先上来就配置大数值CPU预留。预留会锁定物理资源造成集群资源碎片化优先做vCPU裁剪。4、虚拟机热修改vCPU部分操作系统热插拔CPU后系统内部调度依旧异常建议停机调整vCPU。❓FAQ常见问题QCo‑Stop低于多少算正常A理想状态维持在1‑3%以内持续稳定超过5%就需要关注大于10%会明显感知业务卡顿。Q单vCPU虚拟机会出现Co‑Stop高吗A不会。Co‑Stop是多vCPU协同等待指标单vCPU虚拟机Co‑Stop永远为0。遇到Co‑Stop高的虚拟机优先审视vCPU配置是否过大。Q开启CPU预留之后DRS不做虚拟机迁移了ACPU预留会作为DRS放置计算条件如果目标主机没有足够空闲CPU满足预留DRS不会把虚拟机调度过去预留设置过大直接降低集群调度灵活性。总结虚拟机CPU Co‑Stop高核心根源大多是vCPU配置过量。优先评估业务真实负载减少不必要的vCPU业务确实需要多核无法缩减再配置适度CPU预留。不建议盲目调大vCPU也不要滥用CPU预留。区分Co‑Stop与CPU Ready两个指标对症下药完成虚拟化调度调优。