顺德o2o网站建设,windows优化大师软件介绍,骏驰网站开发,天津seo外包团队一次 KVM 虚拟机卡顿排查#xff1a;根因指向宿主机 NUMA balancing 与 KVM MMU 交互 更新时间#xff1a;2026-03-11 注#xff1a;从排查到解决到故障报告输出以及博客编写全是由AI完成。我只提供了机器信息#xff0c;故障描述。后续普通IT民工该何去何从。 摘要 某 KVM…一次 KVM 虚拟机卡顿排查根因指向宿主机 NUMA balancing 与 KVM MMU 交互更新时间2026-03-11注从排查到解决到故障报告输出以及博客编写全是由AI完成。我只提供了机器信息故障描述。后续普通IT民工该何去何从。摘要某 KVM 虚拟机在业务运行时会周期性出现整机卡顿用户侧可观察到秒级ping延迟guest 内还能看到soft lockup、调度异常以及irq/softirq/sys尖峰。初看很像是业务线程卡死、宿主机不给 CPU或者虚拟机内部出现锁竞争。但这次排查最后收敛到的根因并不在 guest 业务逻辑里而是更偏底层宿主机自动 NUMA balancing 与 KVM TDP MMU 交互触发了二级页表频繁 invalidate 和 page fault 回补最终把虚拟机拖入短时间的整机停顿。更关键的是这个判断并不只来自经验猜测而是来自一条比较完整的证据链guest 内的perf sched显示异常线程是sched delay很长而不是wait time很长临时调低soft lockup门限后能看到多类线程同时报错指向整机推进异常host/guest 同时间窗观测表明异常主要消耗在qemu-kvm的 host kernelsystem时间host 上对qemu-kvm做perf直接命中了kvm_tdp_page_fault、kvm_mmu_notifier_invalidate_range_start、change_prot_numa这条链临时关闭kernel.numa_balancing后异常明显收敛本文保留了关键抓取方法和判断过程但去掉了没有推进作用的中间试错细节。1. 问题现象问题表面上并不复杂某 KVM 虚拟机在业务运行时会出现明显卡顿用户侧对虚拟机做ping时偶发出现秒级延迟guest 内部可以观测到perf sched异常、soft lockup、实时 CPU 统计尖峰停掉虚拟机内上层业务后现象明显减轻或消失这类问题很容易让人先怀疑下面几类原因guest 内某个业务线程持锁太久宿主机调度器没有给虚拟机足够 CPUcgroup quota、cpuset 或 memory hard limit 配置不合理网络中断、软中断或者存储抖动导致业务表现为“卡住”真正的难点不在于列出怀疑项而在于尽快把问题收敛到 guest、host 还是 KVM 内核路径。2. 环境背景已脱敏虚拟机侧标识guest内核Linux 4.x虚拟化类型KVM运行环境KubeVirt宿主机侧标识host内核Linux 6.x虚拟机管理方式KubeVirt qemu-kvm映射关系对应qemu-kvm进程qemu-pid对应虚拟机实例vm-instance3. 先回答一个问题线程是在等待还是整机没有推进这次排查真正开始收敛是从 guest 里的perf sched开始的。很多虚拟机卡顿问题第一反应都是“是不是某个线程被锁卡了几秒”。但perf sched很适合先回答一个更本质的问题异常线程到底是在等待还是已经 runnable 却长时间没真正得到运行。常用抓法可以很直接perf sched record-a--sleep60perf sched timehist-iperf.data如果想继续追某个异常窗口前后的切换链可以再看perf script-iperf.data这类数据的判读重点不是“哪个线程名字最显眼”而是下面两个指标wait timesch delay如果一个线程的wait time很长通常更像它真的在等待锁、I/O 或其他阻塞事件如果wait time 0但sch delay却达到秒级就说明它其实已经 runnable只是长时间没真正运行。这次问题里异常样本明显更接近后者。因此怀疑点很快就从“单线程卡住”转成了“虚拟机整体推进异常”。4. 为什么要保留soft lockup的临时调低动作如果把这篇内容写成技术博客我认为soft lockup的临时调低方法应该保留因为它不是无效试错而是提高可观测性的关键手段。为了让异常更快暴露可以在 guest 内临时调低 watchdog 阈值例如sysctl-wkernel.watchdog_thresh1在常见内核实现里这通常会把soft lockup的报警门限压到约 2 秒更容易在问题发生时及时打出告警。这个动作的意义在于放大现象而不是制造问题如果只是某个业务线程自己阻塞通常只会看到少数相关线程受影响如果用户态线程、内核线程、ksoftirqd、swapper等多类线程都陆续报soft lockup那就更像是多 vCPU 一起出现推进异常这次排查中后者恰好就是我们看到的形态。它进一步说明问题不像是单个业务线程的局部死锁而更像整机级的停顿。测试结束后记得恢复原有配置避免长期引入额外告警噪声。5. 把 guest 映射到 host 后很多常见怀疑就可以先排掉只在 guest 内看问题结论通常收不住。下一步一定要把目标虚拟机精确映射到宿主机上的qemu-kvm进程。有了这层映射之后先做的不是立刻上perf而是排除最常见也最容易误判的问题CPU quota 是否节流cpuset 是否绑核过窄memory hard limit 是否触发宿主机或虚拟机生命周期层面是否发生 pause、reset、迁移之类的粗粒度异常这次排查里这些常见限制都没有命中。它的价值很直接避免把问题误判成一个普通的资源配置故障。6. 真正让怀疑点收敛的是 host/guest 同时间窗联动观测只看 guest 或只看 host 都不够。更有效的做法是对同一时间窗做联动采样。guest 侧重点看vmstatmpstat/proc/softirqs/proc/interrupts/proc/net/softnet_statjournalctl -kfhost 侧重点看对应qemu-kvm进程的pidstat针对该进程的perf采样这一步最关键的观察不是“CPU 很高”本身而是CPU 高在哪里。这次问题在复现窗口里表现得很典型guest 内部会突然出现irq/softirq/sys的尖峰runnable 线程数显著堆积同一时间窗里宿主机对应qemu-kvm进程的 CPU 开销主要落在system而不是guest这说明一件很重要的事qemu 的时间并不是花在 guest 指令执行本身而是花在 host kernel 的某条虚拟化相关路径上。到这里为止怀疑点就已经不再是“业务线程是不是写得有问题”而开始明显收敛到 KVM、MMU、page fault 或相关内核路径。7. 最关键的一步直接对qemu-kvm做 host perf这次排查真正把问题钉住是因为没有停留在 host 的宏观 CPU 统计而是直接对对应qemu-kvm进程做了 hostperf采样。这一点很重要。很多类似场景里如果只看perf sched或只看 CPU 使用率最后常常只能得到“确实很忙”这种无效结论而对qemu-kvm本体做perf才能直接看到热点到底落在哪条内核调用链上。关键调用链如下。KVM TDP page fault 链路queued_read_lock_slowpath - kvm_tdp_page_fault - kvm_mmu_page_fault - vmx_handle_exit - vcpu_enter_guest - kvm_arch_vcpu_ioctl_runNUMA balancing 触发 MMU invalidate 链路queued_write_lock_slowpath - tdp_mmu_zap_leafs - kvm_tdp_mmu_unmap_gfn_range - kvm_unmap_gfn_range - kvm_mmu_notifier_invalidate_range_start - __mmu_notifier_invalidate_range_start - change_protection - change_prot_numa - task_numa_work第二条链路几乎已经把问题说透了宿主机自动 NUMA balancing 正在调整 qemu 的内存页这个动作触发了 KVM 二级页表 invalidatevCPU 在线程运行过程中又重新陷入 page fault 与页表回补从 guest 看最终表现成的就是整机卡顿、软中断和内核态尖峰、线程大面积调度异常。8. 用单变量验证把结论压实当调用链已经把怀疑点收敛到宿主机自动 NUMA balancing下一步最合理的动作就是做单变量验证。在宿主机上临时关闭sysctl-wkernel.numa_balancing0关闭之后异常现象明显收敛guest 侧异常尖峰显著减少甚至消失qemu-kvm的system时间明显下降虚拟机内部不再出现此前那种整机级irq/softirq/sys风暴这一步的意义不只是“现象好像改善了”而是它和前面的调用链形成了首尾闭环。换句话说这次判断不是基于相关性瞎猜而是有结构化证据支撑的。9. 最终结论这次问题更接近下面这个模型根因在宿主机自动 NUMA balancingNUMA balancing 触发了 KVM TDP MMU 相关的 invalidate 与 page fault 回补多个 vCPU 因此大量陷入 host kernelguest 侧最终表现为整机短时停顿所以“停掉业务后现象缓解”并不意味着业务本身有 bug。更准确地说业务负载只是把宿主机这一层的内存和虚拟化路径问题放大了。这也是为什么这类问题最容易误判成应用线程死锁单个进程长期占用 CPU宿主机调度不给虚拟机时间片实际上这次问题最核心的结论是业务负载是放大器不是根因。真正的异常发生在宿主机 NUMA balancing 与 KVM MMU 的交互路径上。10. 后续建议短期内如果业务侧现象已经随着关闭kernel.numa_balancing明显收敛可以继续观察业务请求延迟是否恢复正常guest 是否还报soft lockuphost 上对应qemu-kvm是否还出现异常高system时间如果确认问题消失可以考虑在宿主机上持久化配置在/etc/sysctl.d/99-disable-numa-balancing.conf中写入kernel.numa_balancing 0然后执行sysctl--system如果关闭 NUMA balancing 后仍有零星残留卡顿下一步建议优先看THP 策略是否需要从always调整为madvise或neverKubeVirt / qemu 的内存 pinning 策略宿主机是否还存在页迁移、内存回收、脏页回写相关抖动11. 这类问题以后怎么查最后把这次排查里最值得复用的方法抽出来方便以后遇到类似问题直接套用。先在 guest 里区分异常到底是锁等待还是sched delay异常。临时调低soft lockup门限提高整机级停顿的可观测性。把 guest 精确映射到宿主机上的qemu-kvm进程。先排除 quota、cpuset、memory hard limit 这类常见限制。做 host/guest 同时间窗联动采样先判断异常到底集中在哪一侧。不要只看宏观 CPU 指标直接对qemu-kvm做 hostperf。如果命中kvm_tdp_page_fault、kvm_mmu_notifier_invalidate_range_start、change_prot_numa等链路再用关闭kernel.numa_balancing做单变量验证。这套方法对 KVM / KubeVirt 场景下的“虚拟机整机卡顿”问题复用价值很高。