CPU steal 时间长期 >10% 但宿主机空闲的 KVM/QEMU 超分配排查_网络技术

CPU steal 时间长期超10%时，首要排查vCPU竞争、IRQ绑定不均、THP启用、C-state过深及guest时钟源异常；可通过限制CPU配额、分散中断、禁用THP、调整C-state、校准时钟源并升级内核修复。

10% 但宿主机空闲的 kvm/qemu 超分配排查">

当 KVM/QEMU 虚拟机中观察到 CPU steal 时间长期超过 10%，而宿主机整体 CPU 使用率却很低（例如超分配 + 调度竞争导致的，需从资源分配、调度策略和宿主机配置三方面系统排查。

steal 高往往源于 vCPU 过度争抢有限的物理时间片。即使宿主机 load 很低，若多个 VM 的 vCPU 全部绑定在少数几个物理核上，仍会触发严重调度延迟。

用 virsh vcpuinfo 查看当前 vCPU 分配状态，确认是否所有 vCPU 都挤在同一个 NUMA 节点或少量 pCPU 上
用 lscpu 和 numactl --hardware 确认宿主机 NUMA 拓扑；结合 virsh v cpupin 检查是否做了显式绑核，若未绑定，默认由 CFS 调度器统一分配，易造成热点
特别注意：某些云环境或模板镜像默认启用 vcpu placement='static' 但未指定 pin，导致启动时随机绑定，后续无法感知冲突

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 并配合 systemd.slice 限制 CPU quota，或直接使用 virsh schedinfo --set cpu_quota=50000 --set cpu_period=100000（即 50% 硬上限）

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 进入可运行态

部分老版本内核或定制发行版中，/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 数据准确性