steal高而宿主机top显示CPU空闲是因监控视角不同：steal反映vCPU被宿主机强制挂起的时间，而top仅统计物理核的用户/内核态占用，不包含KVM调度延迟；常见于vCPU超分配或绑定不均场景。
为什么 steal 高但宿主机 top 显示 CPU 空闲？
这不是矛盾，而是监控视角错位：steal 是虚拟机内核从自身视角报告的“本该执行却因宿主机调度让出的时间”，它只反映 KVM 的 vCPU 被强制挂起的时长；而宿主机 top 看的是物理 CPU 核心的用户态/内核态占用，不包含被 kvm-kmod 或 qemu 进程主动让出、或被其他 vCPU 抢占导致的调度延迟。常见于超分配 + 高频 vCPU 切换场景。
检查是否真存在 vCPU 超分配（而非内存）
超分配通常指 vCPU 总数远超物理逻辑核数，但很多人只查 lscpu 却忽略 qemu 进程实际绑定策略：
- 运行
ps aux | grep qemu找出对应进程 PID，再执行taskset -cp <pid></pid>确认其绑定的 CPU 范围 —— 如果绑定了 8 个核，但启动时用了-smp 16，那即使宿主机空闲，后 8 个 vCPU 也会持续争抢前 8 个核，触发大量 steal - 检查
/proc/<pid>/status</pid>中的voluntary_ctxt_switches和nonvoluntary_ctxt_switches：若后者远高于前者（比如 5:1），说明 vCPU 频繁被强占，是 steal 上升的直接信号 - 用
virsh vcpuinfo <domain></domain>查看每个 vCPU 当前运行在哪个物理 CPU 上，观察是否集中扎堆（如全挤在 CPU0–3），而非均匀分布
kvm_stat 和 perf kvm 定位 steal 的具体来源
kvm_stat 不显示 steal，但它能暴露底层瓶颈：
Switch Modes
下载
动态切换AI模型以优化成本与性能。当用户发出“eco mode”、“balanced mode”、“smart mode”或“max mode”等模式指令，或使用“/modes status”查询状态及“/modes setup”配置模式时触发。
- 高
exits（尤其是io_window、halt、irq_window）说明 vCPU 频繁进出 guest mode，增加调度开销 - 如果
remote_tlb_flush次数异常高，意味着跨 NUMA 节点访问内存，vCPU 在等待远程 TLB 刷新完成时被计入 steal - 更准的方法是
perf kvm --event kvm:kvm_exit -p <qemu-pid></qemu-pid>，抓几秒退出事件分布：若大量exit_reason=7（HLT）或exit_reason=28（IOIO），说明 Guest 正在轮询或低效等待 I/O，应优化驱动或启用ioeventfd
调整 cpu_mode 和 vcpu 分配策略的实际效果
别迷信 host-passthrough：它虽暴露完整 CPU 特性，但会禁用 KVM 的一些调度优化，反而加剧 steal；实测中 host-model 更稳：
- 对数据库类 VM，把
vcpu数设为物理核心数的 1.2× 内（如 16 核宿主机跑 ≤19 vCPU），并配合cputune.vcpupin固定到特定 core，避免迁移抖动 - 启用
cpu mode='host-model'+feature policy='disable'关闭pdpe1gb等非必要特性，减少 exit 开销 - 若用
virtio-blk，确认启用了ioeventfd=on和queues=N（N ≥ vCPU 数），否则单队列锁会成为 steal 黑洞
真正难处理的是混合负载：既有批处理型 VM（长时间占用 vCPU），又有响应型 VM（短时高频唤醒）。这种情况下 steal 往往不是配置问题，而是调度器无法兼顾吞吐与延迟，得靠 cpu.cfs_quota_us 限频 + cpu.rt_runtime_us 保实时性来硬切资源边界。
