我说老李你说黑凌晨2点17分，手机报警把我从梦里拽出来。客户反馈线上业务全部卡死，登录服务器一看，load average 直接飙到 80 多，top 里 CPU 的 si（软中断）占用超过 90%，整个系统像被人按住了脖子。我第一反应就是：这他妈是中断风暴。
干运维和内核排查这么多年，中断风暴算是“看起来吓人、其实有套路”的典型故障。只要你能冷静下来，按顺序把 /proc/interrupts、/proc/softirqs、mpstat 这几个工具过一遍，大多能在十分钟内定位到真凶。这篇文章我把我实战中遇到过的中断风暴场景、排查思路、止血手段、长期治理方案全部整理出来，希望能帮你少走点弯路。
1. 先搞清楚什么是中断风暴
1.1 中断机制的基本原理
要理解中断风暴，得先回到中断本身。CPU 和硬件设备之间通信，总不能靠 CPU 不停轮询设备“你有没有事”，那样太浪费资源了。所以硬件设备有了事件（网卡收到数据包、磁盘完成 IO、定时器到期），会主动拉高一条中断线，通知 CPU“过来处理我”。CPU 收到这个信号，会暂停当前正在执行的任务，跳转到对应的中断处理程序，处理完再回来继续干活。
这个机制本身没问题，问题出在“频率”上。正常情况下一块千兆网卡每秒产生几千到几万个中断是很正常的，CPU 完全扛得住。但如果因为驱动 bug、硬件故障、配置错误，导致中断以每秒几十万甚至上百万次的频率疯狂触发，CPU 就会把绝大部分时间都花在处理中断上，真正该干活的进程反而抢不到 CPU 时间片。这就是中断风暴，本质上是“中断处理”本身成了系统最大的负担。
我习惯用一个生活化的比喻来解释：想象你正在专心写代码，每过几秒就有一个同事过来问你一个非常简单的问题。偶尔问一次没问题，但如果突然有几百个同事排队来问你“这个按钮放哪”“那个字体用几号”，你这一天啥也干不了，净回答问题了。中断风暴就是这个场景。
1.2 中断风暴的典型表现和危害
中断风暴最典型的表现就是一个字：卡。具体症状通常是这几个：
系统 load average 飙升，经常超过 CPU 核数的好几倍；top 里能看到 CPU 的 si 和 hi 占用极高，si 是软中断，hi 是硬中断；业务响应超时，Ping 能通但 SSH 敲命令明显延迟；/proc/interrupts 里某个中断号的计数增长极其离谱，几秒钟就增加几百万。
危害不只是“卡一下”。极端情况下，中断风暴会导致 CPU 长时间停留在中断上下文里，watchdog 机制会认为系统已经 hang 住，直接触发内核 panic 或者重启。如果集群里有其他节点分担压力还好，如果是单点，那就是妥妥的生产事故。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 排查中断风暴的完整工具箱
2.1 第一现场：/proc/interrupts 和 mpstat 配合使用
排查中断风暴的第一步，是先确认“风暴是不是真的存在”，然后找到是哪个中断号、哪个 CPU 在被轰炸。
最直接的入口就是 /proc/interrupts。这个虚拟文件会列出系统中每个中断号、每个 CPU 上的触发次数、中断名称以及对应的设备驱动。我通常先执行两次 cat，中间间隔 2 秒，对比中断计数的增长量。
bash复制cat /proc/interrupts
sleep 2
cat /proc/interrupts
比如某次我在现场看到的结果大致是这种形态：
text复制 CPU0 CPU1 CPU2 CPU3
24: 980245213 984125632 976845231 982154782 PCI-MSI 458752-edge enp3s0-rx-0
25: 124 133 121 145 PCI-MSI 458753-e