CPU steal 时间是Linux中表示虚拟机就绪却遭hypervisor暂停而无法获得CPU的比例；在VMware中虚高常因调度策略或vmware-tools协作异常导致误报，非宿主机真实过载。
什么是 CPU steal 时间，它为什么在 VMware 中会虚高
CPU steal 时间（steal%）是 Linux top 或 vmstat 中的一个指标，表示虚拟机就绪但被 hypervisor 暂停、无法获得 CPU 时间的比例。关键点在于：它只反映“hypervisor 拒绝调度”的次数，并不区分原因——可能是宿主机真忙，也可能是 VMware 的调度策略或 vmware-tools 与内核协作异常导致的误报。
常见现象是：top 显示 steal% 长期 >20%，而宿主机 esxtop 的 %USED 和 %RDY 均很低（
vmware-tools 版本和 tsc clocksource 是核心变量
旧版 vmware-tools（尤其是 open-vm-tools idle% 或 sys% 的时间计入 steal%。
- 检查当前 clocksource：
cat /sys/devices/system/clocksource/clocksource0/current_clocksource—— 正常应为tsc，若为hpet或acpi_pm，说明 TSC 同步失败，steal 会显著偏高 - 升级
open-vm-tools到 11.3.5+（Ubuntu 22.04+/RHEL 8.6+ 自带）或手动安装最新版；闭源工具请至少到 12.4.0 - 强制启用 TSC（如 BIOS 支持）：
echo 'tsc' | sudo tee /sys/devices/system/clocksource/clocksource0/current_clocksource（临时），并确认kernel.tsc=reliable在启动参数中
VMware 设置里几个容易被忽略的 CPU 相关选项
即使宿主机空闲，某些 VMware 配置也会触发不必要的 vCPU 抢占或调度延迟，间接抬高 steal 计数：
-
cpu.hotadd = "FALSE"（默认）—— 若开启热添加，vCPU 热插拔过程会引发短暂但高频的 steal 尖峰，建议关闭除非真需要 -
monitor_control.restrict_backdoor = "TRUE"—— 关闭后，guest 可能通过 backdoor 调用干扰 hypervisor 时间管理，导致 steal 统计失真；生产环境应保持为TRUE - vCPU 数量 ≠ 宿主机物理核心数时，避免设置
numvcpus = 3这类非 2 的幂值；ESXi 调度器对 2/4/8 等更友好，非对称分配易造成隐式等待
如何验证是不是假 steal，而不是真实性能瓶颈
别只盯着 steal% 数字。真正影响应用的是延迟和吞吐，不是统计值本身：
- 用
perf sched latency查看实际调度延迟分布，如果 99% 的调度延迟 - 运行
stress-ng --cpu 1 --timeout 30s，观察steal%是否随负载线性上升 —— 如果空载高、满载反而下降，基本可断定是 clocksource 或 tools 协作问题 - 对比
/proc/stat中steal字段增长速率和guest字段（vmware-tools 上报的 guest CPU 使用）是否严重偏离；若steal增速远超guest，就是上报失准
最麻烦的情况是：clocksource 正确、tools 最新、配置干净，但 steal 仍持续偏高 —— 这往往意味着 ESXi 主机开启了 CPU resource limits 或 shares 不均，即使整体空闲，该 VM 的配额被其他低优先级 VM 无意挤占，得查 esxtop 的 MLMT（memory limit）和 SWAP 列是否异常，它们有时会连带影响 CPU 调度权重。
