CPU steal 时间长期超10%时，首要排查vCPU竞争、IRQ绑定不均、THP启用、C-state过深及guest时钟源异常；可通过限制CPU配额、分散中断、禁用THP、调整C-state、校准时钟源并升级内核修复。
当 KVM/QEMU 虚拟机中观察到 CPU steal 时间长期超过 10%，而宿主机整体 CPU 使用率却很低（例如 超分配 + 调度竞争 导致的，需从资源分配、调度策略和宿主机配置三方面系统排查。
检查 vCPU 与物理核心的实际映射关系
steal 高往往源于 vCPU 过度争抢有限的物理时间片。即使宿主机 load 很低，若多个 VM 的 vCPU 全部绑定在少数几个物理核上，仍会触发严重调度延迟。
- 用
virsh vcpuinfo查看当前 vCPU 分配状态，确认是否所有 vCPU 都挤在同一个 NUMA 节点或少量 pCPU 上 - 用
lscpu和numactl --hardware确认宿主机 NUMA 拓扑；结合virsh vcpupin检查是否做了显式绑核，若未绑定，默认由 CFS 调度器统一分配，易造成热点 - 特别注意：某些云环境或模板镜像默认启用
vcpu placement='static'但未指定 pin，导致启动时随机绑定，后续无法感知冲突
验证是否启用了 CPU 超售（overcommit）且缺乏节流控制
KVM 允许 vCPU 总数远超物理线程数（如 64 vCPU 跑在 8 核机器上），但缺乏合理节制时，CFS 会频繁推迟低优先级 vCPU，推高 steal。
- 检查
/proc/cpuinfo中的processor数量（即逻辑 CPU 总数），再统计所有运行中 VM 的 vCPU 总和：virsh list --state-running --name | xargs -I{} virsh dumpxml {} | grep "vcpu.*current" | sed 's/.*current=.([^"]*).*/1/' | awk '{s+=$1} END{print s}' - 若总 vCPU >> 物理线程数（建议比值 ≤ 2.5×，高负载场景建议 ≤ 1.5×），且未启用 cgroups v2 或 CPU bandwidth 控制，则 steal 必然升高
- 对关键 VM，可在 XML 中添加
/machine virsh schedinfo（即 50% 硬上限）--set cpu_quota=50000 --set cpu_period=100000
排查宿主机侧干扰性调度行为
steal 时间本质是“本该轮到我执行，却被跳过”，除 vCPU 竞争外，还可能受内核调度器参数、IRQ 绑定、透明大页（THP）等影响。
- 检查是否启用了
intel_idle.max_cstate=1或processor.max_cstate=1：深度 C-state 会导致唤醒延迟，放大 vCPU 调度抖动，尤其在低负载但高精度要求场景下 - 运行
cat /proc/interrupts | grep -E "(eth|nvme|ahci)"，确认硬中断是否集中在一个 CPU 上；用sudo bash -c 'echo 0-3 > /proc/irq/*/smp_affinity_list'（按实际调整）分散 IRQ，避免单核软中断瓶颈 - 临时禁用 THP：
echo never > /sys/kernel/mm/transparent_hugepage/enabled，某些 QEMU 版本在 THP 启用时会加剧内存页分配延迟，间接拖慢 vCPU 进入可运行态
验证 guest 内部是否误判 steal（排除工具链干扰）
部分老版本内核或定制发行版中，/proc/stat 的 steal 统计存在偏差，尤其是启用了 kvmclock 但 host 时间源不稳定时。
- 在 guest 中运行
cat /proc/version和dmesg | grep -i kvmclock，确认是否使用标准 kvm-clock；若显示tsc或acpi_pm，说明时钟源异常，可能导致 steal 计算失真 - 对比
top（显示 steal）与perf stat -e kvm:kvm_exit,syscalls:sys_enter_read ...输出，若 syscall 退出频率正常但 steal 持续偏高，大概率是统计口径问题而非真实调度延迟 - 升级 guest kernel 至 5.10+ 并确保启用
CONFIG_KVM_GUEST=y和CONFIG_PARAVIRT_TIME_ACCOUNTING=y，可显著改善 steal 数据准确性