监控CPU的负载不均衡导致性能问题

现象：线上两套环境配置都是虚拟机32核心CPU，整体数据库，中间件没有太大的差异。但是其中一套环境明显性能不如另一套。

通过使用top命令按1查看每一个CPU核心的负载

#top   按1

很明显负载集中在前16核心上。

下面是每一列的详细介绍：

列名	全称	说明
us	User Space	用户态进程占用 CPU 时间百分比（非 nice 优先级进程）
sy	System	内核态（系统调用、中断处理等）占用 CPU 百分比
ni	Nice	低优先级（nice 值 >0）的用户进程占用百分比
id	Idle	CPU 空闲时间百分比
wa	I/O Wait	等待 I/O 操作完成的阻塞时间百分比（高值可能表示磁盘瓶颈）
hi	Hardware IRQ	处理硬件中断的时间百分比（如网卡、磁盘控制器等硬件触发的中断）
si	Software IRQ	处理软件中断的时间百分比（如网络数据包处理、定时器等软中断）
st	Steal Time	虚拟化环境下被 Hypervisor 偷走的时间百分比（仅虚拟机有效）

通过采集每一个核心的si值监控长期运行曲线

下图中突出就是一部分CPUsi值很高，处于压力高峰：

查看同时期的CPU负载：

系统负载：

可以看出负载比较高，实际上一般CPU没有充分利用起来。

还可以查看interrupts得到更加详细的CPU每一个核心的中断统计

#cat /proc/interrupts

cat /proc/interrupts 命令用于查看 Linux 系统中硬件中断（IRQ）的统计信息。它会显示每个 CPU 核心处理的中断次数、中断类型（如硬件设备、定时器、网络卡等）以及对应的中断号（IRQ number）。

 

简单来说从左到右，分别为：1、逻辑中断号，2、中断在各CPU发生的次数，3、中断所属设备类名称，4、硬件中断号，5、中断处理函数。

详细解释

列名	说明
第一列（如 0:）	中断号（IRQ number），NMI 和 LOC 是特殊中断。
CPU0, CPU1, ...	每个 CPU 核心处理该中断的次数。
中断控制器（如 IO-APIC、PCI-MSI）	中断的触发方式（如 APIC、MSI）。
设备/中断源（如 timer、enp0s3）	触发中断的硬件设备或事件（如网卡、键盘、定时器等）。

 

主要用途

1. 排查高负载问题

   • 如果某个 CPU 核心的中断数远高于其他核心，可能说明 中断负载不均衡，需要调整 IRQ 亲和性（irqbalance 或手动绑定）。

   • 例如，网卡中断（如 enp0s3）集中在 CPU0，可能导致单核高负载。

2. 识别硬件设备中断

   • 可以查看 哪个设备触发了最多中断（如网卡、磁盘控制器、USB 设备）。

3. 监控中断变化

   • 多次运行 watch -n 1 'cat /proc/interrupts' 可动态观察中断增长情况，排查异常中断风暴。

4. 调试驱动程序或内核问题

   • 如果某个设备的中断异常增长（如网卡中断暴增），可能是驱动或硬件故障。

常见中断类型

中断号/名称	说明
0 (timer)	系统定时器中断，通常均匀分布在各 CPU。
1 (i8042)	键盘/鼠标中断（PS/2 接口）。
8 (rtc0)	实时时钟（RTC）中断。
24+ (PCI-MSI)	网卡、显卡等 PCI 设备的中断（如 enp0s3 是网卡）。
NMI	不可屏蔽中断（硬件严重错误时触发）。
LOC	本地定时器中断（每个 CPU 核心的本地事件）。

 

总结

• /proc/interrupts 是分析硬件中断的重要工具，定位 CPU 负载不均或设备问题。

• 结合 mpstat（查看 CPU 使用率）和 top，可以全面诊断系统性能瓶颈。

• 如果发现某个设备中断异常，可能需要更新驱动或调整 IRQ 分配策略，如果是虚拟化平台。

在虚拟机环境中，观察到只有前 16 个 CPU 核心的软中断（si）值很高（>5%），而后 16 个核心的 si 值很低（<1%）时，这通常与 虚拟化平台的中断处理和 CPU 分配机制 有关。

以下是根本原因分析和解决方案：

一、核心原因：虚拟化平台的 CPU 绑定不对称

1. 虚拟网卡中断分配不均

• 虚拟机接收网络数据包时，虚拟网卡（如 virtio-net）的中断默认可能只绑定到部分 vCPU（如前 16 个核心）。

• 检查中断绑定：

 

# 查看哪些中断绑定到前16核心
grep -E "virtio.*input" /proc/interrupts | awk '{print $1}' | cut -d: -f1 | xargs -I{} cat /proc/irq/{}/smp_affinity_list

 输出可能显示类似 0-15（表示只绑定到前16 个核心）。

还有其他一些原因也要注意：

2. vCPU 调度不对称

• 虚拟化平台（如 VMware/KVM）可能将 物理 CPU 资源优先分配给前 16 个 vCPU，导致后 16 个 vCPU 被限制或调度优先级低。

• 宿主机层面可能存在 CPU 亲和性（affinity）设置不均衡。

3. 多队列未启用或配置错误

• 高性能虚拟网卡（如 SR-IOV/virtio-net）需要 启用多队列（Multi-Queue） 才能将中断分发到多个 vCPU。