Linux中断风暴本质是硬件中断频率超CPU处理能力，致硬/软中断霸占CPU、业务线程被挤压；需通过mpstat、/proc/softirqs、/proc/interrupts交叉验证，定位源头在硬中断侧，并检查驱动合规性及系统参数协同调优。
Linux 中断风暴本质是硬件中断频率远超 CPU 处理能力，导致硬中断和软中断持续霸占 CPU 时间，业务线程被严重挤压甚至无法调度。排查不能只看表象（比如 %si 高），而要顺着“硬件触发 → 中断分发 → 延迟处理”这条链路逐层验证。
确认是否真发生了中断风暴
单看 top 里 %si 或 %hi 高并不足够，需交叉验证三组数据：
- 运行 mpstat -P ALL 1，观察各 CPU 的 %hi 和 %si 是否长期 >15%，且集中在 1–2 个核上
- 执行 cat /proc/softirqs，重点盯 NET_RX、TIMER、SCHED 这三列——若某 CPU 上 NET_RX 每秒增长超 10 万，基本可判定为网络类中断风暴
- 用 watch -n 1 'cat /proc/interrupts' 动态观察，看是否有某个 IRQ 号（如 eth0、XL9535 对应的中断）计数在几秒内暴涨数十万次
定位中断源头：从硬中断开始查
软中断是硬中断触发的“下游”，风暴根源几乎总在硬中断侧：
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- 查具体设备中断分布：grep eth0 /proc/interrupts 或 grep gpio /proc/interrupts，确认是否所有中断都砸在 CPU0 上
- 查网卡硬件队列能力：ls /sys/class/net/eth0/device/msi_irqs/ 看有多少个 MSI-X 向量，数量应 ≥ CPU 核数；若只有 1 个，说明网卡本身不支持多队列，软中断必然集中
- 查 GPIO 扩展芯片等外设：像 XL9535 这类芯片，若原理图漏接上拉电阻，引脚会反复抖动触发边缘中断，表现为“一开始正常、一分钟后中断被禁用（nobody cared）”
检查中断处理逻辑是否合规
驱动或内核模块若在中断上下文中做了违规操作，会放大延迟、诱发连锁中断：
- 中断处理函数中禁止调用 kmalloc(GFP_KERNEL)、mutex_lock、msleep 等可能睡眠的函数
- 中断处理时间应控制在 10–100μs 内；可用 ftrace 测量：echo function_graph > /sys/kernel/debug/tracing/current_tracer，再触发中断后查看 trace 日志
- 检查设备树中 interrupts 属性是否匹配硬件，例如是否误将 IRQ_TYPE_EDGE_BOTH 用于本该是电平触发的传感器
系统级配置与调优要点
参数调整必须成套进行，孤立修改往往无效甚至恶化问题：
- RPS（Receive Packet Steering）必须开启：echo ff > /proc/sys/net/core/rps_cpu_mask（8 核系统用 ff，16 核用 ffff），否则软中断无法跨核分发
- net.core.netdev_budget 不宜盲目调大；千兆网卡建议设为 60–120，万兆设为 120–240，同时配套增大 net.core.netdev_max_backlog（≥5000）
- 避免 RPS、RSS、XPS 映射冲突：若 RSS 将包分发到 CPU2/CPU3，RPS 却只允许 CPU0/CPU1 处理，就会频繁触发 soft lockup 报警
