KVM虚拟机卡顿问题排查与NUMA平衡调优

1. 问题背景与现象描述

最近在维护一套基于KubeVirt的虚拟化平台时，遇到一个相当棘手的案例：某台KVM虚拟机在业务负载下会周期性出现整机卡顿现象。从用户侧观察，最直观的表现就是ping延迟突然飙升到秒级，同时虚拟机内部出现大量soft lockup告警和调度异常。

作为有十年经验的系统运维工程师，我第一反应是检查以下几个常见嫌疑点：

• 业务线程是否存在死锁
• 宿主机CPU调度是否出现问题
• 虚拟机内部是否存在资源竞争

但通过初步排查，这些常规猜测都被排除了。更令人困惑的是，当停掉虚拟机内的上层业务后，卡顿现象确实会减轻，但这并不意味着问题就出在业务代码本身。

2. 环境配置与排查工具准备

2.1 环境拓扑

• 宿主机：Linux 6.x内核，运行KubeVirt管理虚拟机
• 虚拟机：Linux 4.x内核，运行业务应用
• 虚拟化层：qemu-kvm实现

2.2 关键排查工具

在本次故障排查中，以下几个工具发挥了关键作用：

1. perf：用于分析调度延迟和热点函数
2. vmstat/mpstat：监控系统级资源使用情况
3. pidstat：跟踪特定进程的资源消耗
4. 内核日志：通过journalctl查看soft lockup等内核事件

提示：在进行性能分析前，建议先建立完整的数据采集方案，包括采样频率、存储位置和保留策略，避免在问题复现时手忙脚乱。

3. 问题定位过程详解

3.1 初步现象分析

通过perf sched工具，我们首先确认了一个重要事实：异常线程的wait time为0但sch delay达到秒级。这说明线程已经处于可运行状态，却长时间得不到CPU资源。

这与传统锁竞争问题的表现（wait time长）有本质区别，暗示问题可能出在更底层的调度机制上。

3.2 关键转折点：soft lockup阈值调整

为了放大问题现象，我们临时调整了虚拟机的watchdog阈值：

bash复制sysctl -w kernel.watchdog_thresh=1

这个操作带来了两个重要发现：

1. 不仅业务线程，连内核线程(ksoftirqd)、空闲线程(swapper)都出现了soft lockup
2. 多种线程同时报错，