我们有一台部署在香港机房的高性能物理服务器，跑的是边缘加速业务，延迟表现尤为关键。某天，接到监控告警：用户反馈RT（Response Time）不稳定，间歇性抖动甚至出现丢包。我第一时间 SSH 上去检查，发现系统负载并不高，CPU利用率也在可控范围，但奇怪的是，软中断（softirq）异常占高，且集中在某几个核上，这很不正常。

这让我想起了之前一次 DDoS 缓解期间的经验，于是展开了深入排查，最终锁定原因并用 irqbalance 配合 CPU 绑定做了优化，效果立竿见影。下面是这次的复盘与实操，希望能帮到面临类似问题的你。

一、问题初现：软中断占用高导致RT波动

先贴一下当时的 top 和 mpstat 观测输出（精简处理）：

top - 12:15:42 up 5 days,  3:21,  2 users,  load average: 3.25, 3.10, 3.05
%Cpu0  : 15.3 us,  2.1 sy,  0.0 ni,  0.0 id, 82.5 si,  0.0 hi,  0.0 st
%Cpu1  :  3.1 us,  1.1 sy,  0.0 ni, 95.7 id,  0.1 si,  0.0 hi,  0.0 st
...

我注意到 CPU0 的 si（softirq）占比超过 80%，这说明大多数中断处理都集中在这个核心上。而网络服务进程绑定在用户态的其他核，虽然总体 CPU 利用率不高，但系统中断带来的干扰是不可忽视的，这正是RT波动的根因。

二、初步排查：定位瓶颈来源

1. 查看软中断集中在哪些中断号上：

cat /proc/interrupts | grep eth

输出类似如下：

  42: 2457612197   0   0   0   0   0   0   0  IR-PCI-MSI  eth0-rx-0
  43:   14593282   0   0   0   0   0   0   0  IR-PCI-MSI  eth0-tx-0

可以看到，大量的中断集中在 eth0-rx-0（接收队列0）上，且明显分配在 CPU0 上。由此可判断为网卡接收中断负载不均。

2. 验证网卡是否支持多队列（RSS）

ethtool -l eth0

若显示 Combined: 4 或更多，说明网卡支持多队列，我们就可以做更精细的中断绑定。

三、解决方案设计：irqbalance + 中断重定向 + 进程绑核

我采用了三步组合拳：

• 启用并配置 irqbalance，让系统中断更均匀分配。
• 手动 fine-tune 关键网卡中断绑定到特定 CPU。
• 将业务进程绑核到与中断核分离的 CPU，以减少调度抖动。

四、实操步骤详解

Step 1：安装与启用 irqbalance

yum install irqbalance -y
systemctl enable irqbalance
systemctl start irqbalance

默认启用后，irqbalance 会根据中断频率自动将其分发到较空闲的CPU核上。但它并不保证完美分配，有时还需要手动干预。

Step 2：手动绑定中断到特定CPU核

在高并发业务下，我倾向于将接收中断(rx)绑定到专门的几个CPU核（比如CPU1、CPU2），并避开业务主线程所在的核心。

1. 确定中断号与队列：

grep eth0 /proc/interrupts

假设 eth0-rx-0 中断号为 42，我们可以将它绑定到 CPU1：

echo 2 > /proc/irq/42/smp_affinity

smp_affinity 是一个 bitmap，这里的 2 是二进制的 10，表示绑定到 CPU1。

可以批量设置：

for i in {42..45}; do
    core=$(( (i-42)%4 + 1 ))  # 假设绑定 CPU1-CPU4
    mask=$((1<<core))
    printf "%x" $mask > /proc/irq/$i/smp_affinity
done

Step 3：业务进程绑核（隔离用户态与中断核）

我们使用 taskset 工具将主业务程序绑定在中断不干扰的 CPU 核上，比如 CPU5-CPU7：

taskset -c 5-7 ./your_app_binary

或者在 systemd 配置文件中：

[Service]
ExecStart=/usr/bin/your_app_binary
CPUAffinity=5 6 7

五、效果验证与持续监控

验证软中断是否均衡分布

watch -n 1 cat /proc/interrupts | grep eth

你应当看到中断计数在多个 CPU 核之间增长，而不是集中在 CPU0。

验证应用性能

我们上线后进行了多轮压测与业务观察，RT 抖动从最高 200ms 降到不足 20ms，系统负载也更平稳。更重要的是，中断不再干扰主业务核心，系统响应稳定性大幅提升。

六、一些经验与Tips

• 避免把所有中断绑定到 NUMA 节点跨核，否则反而加重 L3 cache miss。
• irqbalance 虽好，但不是万能——关键业务场景还是需要手动精细配置。
• 网卡的 ethtool -x 支持可进一步自定义 RSS 队列映射。
• 如果使用 DPDK、XDP 等绕过内核的技术，也应考虑 CPU NUMA 亲和性设计。

软中断过载是很多人容易忽视的性能杀手，尤其在高性能网络服务中，一点中断分配不均就可能引发连锁反应。借助 irqbalance 配合手动 CPU affinity 配置，可以显著优化 RT 稳定性。

面对复杂的问题，冷静分析、定量观察、系统性调优，永远是最靠谱的解决之道。