Linux软中断风暴诊断与优化实战

1. Linux软中断风暴现象解析

第一次遇到软中断风暴时，我正负责维护一个电商大促期间的服务器集群。凌晨3点，监控系统突然报警显示多台机器负载飙升，但奇怪的是CPU使用率显示"空闲"。登录机器后发现top命令都卡得无法响应，好不容易执行后看到%si指标高达98%，这才意识到遇到了传说中的软中断风暴。

软中断风暴的本质是内核的软中断处理机制被异常流量或硬件故障"绑架"。正常情况下，软中断作为中断下半部（bottom half）机制，用于延迟处理耗时操作。但当某个软中断类型被高频触发时，就会形成恶性循环：

1. 硬中断快速触发软中断
2. 软中断处理函数执行时间过长
3. 新的硬中断不断产生
4. CPU陷入软中断处理的死循环

这种情况下的典型表现包括：

• top命令中%si（软中断）指标持续高于70%
• ksoftirqd内核线程占用率异常高
• 系统响应迟缓，连ssh命令都出现明显卡顿
• 常伴随内核日志中的soft lockup告警

关键提示：当系统出现"高负载但低CPU使用"的矛盾现象时，软中断风暴是需要首要排查的方向。我曾遇到一个案例，16核服务器的load average达到200+，但%us（用户态CPU）只有3%，最终发现是网卡驱动缺陷导致的NET_RX软中断风暴。

2. 软中断机制深度剖析

2.1 从硬件中断到软中断的完整路径

理解软中断风暴需要先掌握Linux中断处理的完整流程。以网络数据包接收为例：

1. 硬件中断阶段：

   • 网卡收到数据包后通过DMA写入内存
   • 触发硬件中断（IRQ），CPU跳转到中断向量表
   • 执行网卡驱动注册的中断处理函数（上半部）
   • 上半部函数快速应答硬件后，调用raise_softirq(NET_RX_SOFTIRQ)标记软中断

2. 软中断触发阶段：

   • 在以下时机检查并处理软中断：
     • 硬中断返回时（irq_exit）
     • 内核线程ksoftirqd被唤醒时
     • 显式调用local_bh_enable时
   • 通过__do_softirq()函数处理pending的软中断

3. 网络栈处理阶段：

   • NET_RX