中断风暴排查指南：从硬中断到软中断的CPU性能优化

1. 中断风暴的真面目：硬中断与软中断的连锁反应

1.1 先搞清楚中断到底在做什么

很多做运维和嵌入式开发的朋友，一听到“中断风暴”这三个字就头皮发麻。我在一线排查过不少服务器假死、网络吞吐暴跌的故障，十次里有三四次都能在日志和性能数据里抓到中断风暴的影子。要理解它，得先把中断机制本身捋清楚。

CPU 在执行指令的时候，随时可能被硬件设备打断，比如网卡收到一个数据包、磁盘完成了读写、定时器到了时间点，这些设备会向 CPU 发送一个电信号，CPU 收到信号后暂停手头的工作，转去执行一段对应的处理程序，处理完再回来继续干活。这个过程就是中断。中断是操作系统的“神经反射”，没有它，CPU 就得轮询所有硬件，效率低得没法看。

Linux 把中断处理拆成了两段。上半部分是硬中断（hardirq），处理器接收到硬件信号后立刻执行，要求速度快、不能阻塞，通常只做最要紧的事，比如把数据从设备复制到内存、标记一个待处理的标志位，然后赶紧返回。下半部分是软中断（softirq），硬中断把重活留给它，比如网络数据包的协议栈处理、块设备的 IO 完成回调，这些工作可以在更合适的时机慢慢做。

这么设计的原因很直白：硬中断执行期间，CPU 在同一个核上不能响应其他中断，如果硬中断处理时间太长，其他设备就会“干等”，甚至丢数据。而软中断可以被调度、可以被抢占，灵活得多。Linux 内核在硬中断处理函数返回前会检查软中断的 pending 位，如果有就顺手处理一批，这样既保证了及时性，又避免中断上下文占用过久。

1.2 中断风暴就是 CPU 被“打断腿”了

中断风暴，简单说就是一段时间内，系统收到中断请求的频率远远超过了它能处理的合理范围，导致 CPU 把大量时间花在处理中断本身上，而不是执行用户进程和业务逻辑。这时候系统负载看着不见得高，但业务就是卡顿、吞吐量上不去，因为 CPU 的时间片全被“偷”走了。

有一个类比特别好理解：你正坐在工位上写代码，旁边有人每隔几秒就拍你肩膀问一句“在吗”。虽然每次问话只有一秒钟，但你的思路完全断了，一上午下来代码没写几行，全在“被打断—恢复—再被打断”的循环里。CPU 遇到中断风暴就是这个状态。

中断风暴有两个层面。一层是硬中断频率本身暴涨，比如网卡在高速收包时每收到一个包就触发一次中断，包量一大，中断频率就跟着飙升。另一层是硬中断频率不高，但每次硬中断触发的软中断处理特别耗时，比如网络数据包处理逻辑重、锁竞争激烈，软中断堆积越来越多，CPU 在 softirq 里消耗的时间占比越来越大。两个层面经常同时出现，搅在一起，排查时容易晕头转向。

判断中断风暴最直接的办法是看系统统计。/proc/interrupts 文件记录了每个 CPU 核上每种中断源触发的次数，两次采样间隔内数值暴涨，说明中断频率异常。另一个是 top 命令里看 CPU 的使用率分布，如果 si（softirq 软中断）长期占据高位，比如超过 30%，那基本可以断定软中断处理成了瓶颈。

注意：si 高不代表一定就是坏事。高吞吐的网络服务器、繁忙的存储节点，软中断占用一部分 CPU 是正常的。真正需要警惕的是 si 数值长期居高不下，同时业务吞吐没有相应增长，或者 CPU 之间负载严重不均衡，某个核的 si 跑到 80% 以上，其他核空闲，这种“一边忙死一边闲死”的状态，十有八九是中断分配出了问题。

2. 中断风暴的高发场景：网卡、驱动与硬件异常

2.1 网卡收包中断：最经典的高频中断源

网络设备是中断风暴的头号来源，尤其在高 PPS（每秒数据包数）场景下。以前网卡收包是一个包一个中断，10 兆、100 兆网络时代这没什么问题，但是到了千兆、万兆，小包突发情况下每秒几十万甚至上百万个包，如果每个包都触发一次中断，CPU 就啥也别干了，光响应中断就耗尽算力。

现代网卡普遍支持中断合并（coalescing），驱动可以配置收包后先攒一批再上报中断，或者用定时器周期性检查。中断合并的配置有几个关键参数，比如 rx-usecs 表示收到包后最多延迟多少微秒产生中断，rx-frames 表示攒够多少个帧才产生中断。这两个值调大了，CPU 中断频率降下来了，但延迟会上升；调小了，延迟降低，中断频率上升。实际调优要在延迟和吞吐之间找平衡点。

另一个重要机制是 NAPI。NAPI 是 Linux 网络子系统为了对抗中断风暴设计的经典方案：网卡产生第一个中断后，驱动立刻关掉该队列的中断，然后切换到轮询模式，从环形缓冲区里把数据批量取出来送到协议栈，直到取空了再重新开启中断。这样在高速收包场景下，中断次数和包数不再是一比一的关系，中断数量被压得很低。NAPI 的 weight 参数控制一次轮询最多处理多少个包，默认是 64，处理完如果还有包，就等到下一个软中断周期继续处理。

我在实际排查中见过一个典型的反面案例。有台服务器做流量转发，万兆网卡，业务方反馈转发性能只有预期的一半。抓数据发现每个 CPU 核的硬中断次数并不高，但是某个核的 si 占用到了 90% 以上，其他六个核几乎空闲。原因是网卡只有一个队列，所有收包中断都路由到了 CPU0，CPU0 在软中断里处理大量的包，其他核帮不上忙。后来把网卡多队列打开，配置了 Receive Side Scaling（RSS），让不同队列的中断分散到不同 CPU 核，再配合 RPS（Receive Packet Steering）做软件层面的负载均衡，吞吐直接翻倍。这类问题本质上不是中断频率失控，而是中断负载分布不均导致的局部“风暴”。

2.2 驱动缺陷：中断请求却无事可做

驱动代码写得不讲究，也会人为制造中断风暴。有一种常见的情形是设备中断状态没有及时清除。中断处理程序跑完忘记写清除寄存器，或者清状态的时序不对，设备认为 CPU 还没处理完，立刻又发一个中断，CPU 再进中断处理程序，又没清干净，于是形成死循环式的连续中断。表现出来就是某个中断号在 /proc/interrupts 里疯狂自增，CPU 被钉死在硬中断里，系统响应迟缓甚至完全卡死。

还有一种情况是共享中断处理程序互相“抢活”。传统 PCI 设备经常多个设备共享一条 IRQ 线，中断到来时内核要依次调用该 IRQ 上注册的所有中断处理程序，直到某个处理程序确认“这中断是我家的”。如果某个驱动写得比较粗暴，不管中断是不是自己设备的都返回 IRQ_HANDLED，就会把本该属于别人的中断吞掉；反过来，如果设备产生中断但所有 handler 都返回 IRQ_NONE，内核会报 “nobody cared” 错误，同时禁用这个 IRQ，设备从此彻底“失联”。

驱动引发的风暴在版本升级后尤其容易冒出来。内核版本和驱动版本不匹配、固件版本过旧、DMA 缓冲区分配失败导致设备反复重试，都可能让中断频率异常。排查驱动类问题，我建议先看 dmesg 里有没有对应的告警或者错误信息，再看网卡 ethtool 的统计计数，比如 rx_error、rx_missed、rx_no_buffer 这些计数器是不是在涨。很多时候中断风暴只是表象，真实原因是设备在底层反复出错、反复重试，驱动层面没有做好错误率控制和退避。

2.3 定时器与硬件故障：容易被忽略的“隐性风暴”

除了网卡，定时器中断也需要注意。Linux 内核有周期性的时钟中断，用于进程调度、时间片计算等基础功能。大多数架构上，内核支持动态时钟（dynticks / NO_HZ），空闲的 CPU 可以关闭周期性时钟，减少无谓的唤醒。但如果系统配置了高精度定时器（hrtimer），并且有大量短周期定时器在排队，比如某些应用每毫秒唤醒一次，CONFIG_HZ 配置又很高（比如 1000Hz），软中断里的定时器处理就会消耗掉不少 CPU。虽然这类问题通常不会被叫做“中断风暴”，但排查思路上是同一类：某个内核机制触发频率过高，挤占了有效计算资源。

硬件故障层面的“中断风暴”有时候很隐蔽。PCIe 设备出现 AER 错误、链路降速、故障重传时，会不断上报错误中断，如果驱动没有做错误抑制（error containment），系统可能进入“报错—重试—再报错”的恶性循环。我遇到过一块 RAID 卡电池电量低，每秒钟上报一次警告中断，CPU 的 si 被顶到 20% 以上，业务进程延迟明显变大。把电池换掉之后一切恢复正常。所以排查中断风暴时不要只盯着网卡，/proc/interrupts 里哪个中断号涨得最快，就顺着它去查对应的硬件设备和驱动。

3. 排查方法论：从数据到根因，一步步缩小范围

3.1 第一手证据：读 /proc/interrupts 的正确姿势

排查中断风暴，第一步永远是打开 /proc/interrupts 看数据。这个虚拟文件是内核中断子系统暴露的窗口，每一行对应一个中断号，列对应各个 CPU 核上的触发次数。

最基础的做法是两次采样做差值：

bash复制cat /proc/interrupts > /tmp/int1
sleep 5
cat /proc/interrupts > /tmp/int2
diff /tmp/int1 /tmp/int2

这样能快速看出 5 秒内哪个中断号的计数暴涨。如果某个中断从几万涨到几百万，大概率问题就在它身上。

看的时候还要关注几个点。第一，中断在 CPU 核上的分布是否均匀。如果几乎所有增量都落在同一个核上，说明内核的默认路由策略或者设备的 MSI-X 配置没有把队列分散开。第二，/proc/interrupts 里每行开头如果带 PCI-MSI 字样，说明设备用的是 Message Signaled Interrupts，每个队列有独立的中断号，这类设备做负载均衡比传统共享中断要方便得多。第三，看 CPU0 到 CPU15 那一列里有没有异常高的值，比如某个核的计数比别的核高几个数量级，那基本就是 IRQ 亲和性配置失效，所有中断都挤在一个核上。

采样工具方面，watch -n 1 cat /proc/interrupts 可以实时盯着看，或者用 mpstat -I CPU 1，这个命令能分开展示每个 CPU 每个中断事件的频率和 CPU 时间占比，比直接看 /proc/interrupts 更直观。mpstat -I CPU 的输出里会列出每个 CPU 上的中断总数和硬中断、软中断的时间比例，比手动 diff 高效得多。

3.2 从 top 到软中断细节：si 高不等于一切

top 命令第一行能看到 CPU 使用率分布，其中 si 是软中断占用，hi 是硬中断占用。很多朋友一看到 si 高就喊“中断风暴”，这个结论下得太急了。软中断高有两种可能：单位时间内中断确实太多，或者每个中断的处理本身太重。这两种情况的解法截然不同。

需要进一步看的是 /proc/softirqs。这个文件按 CPU 核展示了各类软中断的累计次数，包括网络收发相关的 NET_RX 和 NET_TX、块设备相关的 BLOCK、定时器相关的 TIMER 和 HRTIMER、任务调度的 TASKLET 等。同样做两次采样差值，看哪个类别的计数在疯涨。

如果 NET_RX 涨得最快，说明网络收包是主要压力源，接下来看网卡的队列和中断分配。如果 TIMER 涨得离谱，说明系统里高频率定时器太多，得查是哪些内核模块或者用户态程序在大量设置短周期定时器，可以用 perf 或者 ftrace 抓 hrtimer 的调用栈来定位。如果 BLOCK 明显偏高，那就去看存储设备的 IO 队列和中断合并配置。

perf 在这个阶段非常有用。perf top 可以实时看到 CPU 在哪些内核函数上消耗时间：

bash复制perf top -C 3

如果看到 softirq_net_rx、process_backlog、napi_poll 这类函数占据榜首，基本可以确认是网络软中断处理过重。如果看到 irq_work_run、tick_sched_handle 这类，说明时钟中断和调度相关的开销异常。按 CPU 核去看（-C 指定核号），能精准定位是哪个核在忙什么。

3.3 定位根因：中断亲和性、队列配置与 irqbalance

数据收集齐了，下一步是把问题范围从“系统级”缩小到“设备级”再到“配置级”。

先说中断亲和性。Linux 用 smp_affinity 控制某个中断号可以投递给哪些 CPU。每个中断号在 /proc/irq/[irq_num]/smp_affinity 文件里，是一个十六进制位图。比如 00000003 表示只能投递给 CPU0 和 CPU1。默认情况下，内核启动早期中断会集中到 CPU0，用户态服务起来之前，irqbalance 守护进程通常会接手，定期根据系统负载动态调整亲和性。

smp_affinity_list 的格式更友好，直接写 CPU 编号：

bash复制echo 2-3 > /proc/irq/46/smp_affinity_list

这样就把 46 号中断绑定到了 CPU2 和 CPU3。注意，对 MSI-X 设备来说，每个队列有独立的中断号，可以把 1 号队列绑 CPU0、2 号队列绑 CPU1，做一个一对一的均衡。

再说网卡队列。ethtool -l eth0 可以查看网卡当前队列数：

bash复制ethtool -l eth0
Channel parameters for eth0:
Pre-set maximums:
RX:             16
TX:             16
Other:          1
Combined:       16
Current hardware settings:
RX:             8
TX:             8
Other:          1
Combined:       8

如果最大支持 16 个队列但当前只开了 8 个，可以考虑增大。用 ethtool -L eth0 combined 16 可以修改。队列数上限受 CPU 核数和网卡型号双重限制，并不是越大越好，队列比核多没有意义，反而增加无谓的开销。

最后要检查 irqbalance 的运行状态。很多发行版默认开启了 irqbalance，它在系统负载变化时会自动调整中断亲和性。但生产环境里，特别是对延迟敏感的服务器，我通常建议关掉它，手动配置亲和性：

bash复制systemctl stop irqbalance
systemctl disable irqbalance

手动配置的前提是明确了解业务类型和流量模型，如果你不确定哪个核该绑哪个队列，用默认的 irqbalance 可能比瞎配更稳妥。

4. 实战优化：从软硬中断到网卡队列的完整调优手段

4.1 调整中断亲和性：让每个核各司其职

中断亲和性调优的目标，通俗讲就是“把不同的活分给不同的核”，避免所有中断挤在一个核上形成局部风暴。配置方式不复杂，难点在于怎么做规划。

第一步，识别中断号。用 cat /proc/interrupts 找到目标设备对应的中断号。比如一块双口万兆网卡，每个口 8 个队列，每个队列对应一个 MSI-X 中断号。你要做的，是把这些中断分别绑定到不同的物理核上。

第二步，确认 CPU 拓扑。用 lscpu 看哪些是物理核、哪些是逻辑核。同一物理核的两个逻辑核（超线程）共享执行单元，中断绑到两个逻辑核上并不能做到真正并行。理想情况是把不同队列绑到不同物理核上，并预留几个核专门跑业务进程，避免业务和中断抢资源。

第三步，写亲和性配置。注意如果系统里有 NUMA，最好把中断绑到和设备所在 NUMA 节点相同的 CPU 上，因为跨 NUMA 访问内存有额外的延迟和带宽损耗。可以用 cat /sys/bus/pci/devices/[设备地址]/numa_node 查设备所在的 NUMA 节点。很多性能问题的根源不是中断风暴本身，而是中断处理的 CPU 和设备内存所在 NUMA 节点不一致，导致每次收包都要跨 NUMA 访问 DMA 缓冲区，延迟大增。

最后还要考虑业务进程的绑定。如果中断绑到 CPU0-3，而业务进程绑到了 CPU4-7，二者井水不犯河水，这种隔离效果最好。可以用 taskset 或者 cgroup cpuset 来控制用户态进程的 CPU 亲和性。实际项目中，我曾经把网卡中断绑在物理核 0-3，把 nginx worker 绑在 4-7，整机吞吐提升了将近 30%，而且延迟抖动明显下降。

4.2 网卡多队列与 RSS/RPS：从硬件到软件的负载均衡

网卡多队列是现代网卡对抗收包中断风暴的硬件基础。每个队列都有自己的 DMA 环形缓冲区，也能产生独立的中断，多个队列同时收包，多个 CPU 核分摊处理。RSS（Receive Side Scaling）是网卡硬件根据包头哈希值把流量分散到不同队列的机制，哈希因子可以配置，比如根据 IP 四元组哈希，保证一条 TCP 流固定落在同一个队列里，避免乱序。

启用 RSS 的关键是配置哈希键和队列数：

bash复制ethtool -N eth0 rx-flow-hash tcp4 sdfn
ethtool -L eth0 combined 8

rx-flow-hash tcp4 sdfn 表示对 IPv4 TCP 流量，哈希时使用源 IP（s）、目的 IP（d）、源端口（f）、目的端口（n）。有些场景下想只按四元组的一部分做哈希，比如 L4 负载均衡后端希望同一连接的两个方向都落到同一个 queue，就得调整哈希因子，这个细节经常是性能调优的关键。

如果网卡不支持硬件多队列，或者队列数少于 CPU 核数，Linux 还提供了软件层面的 RPS（Receive Packet Steering）。RPS 在 softirq 阶段根据包的哈希值把数据包分发到目标 CPU 的 backlog 队列，由目标 CPU 来执行协议栈处理。配置方法：

bash复制echo 7 > /sys/class/net/eth0/queues/rx-0/rps_cpus

这里的 7 是位图，表示允许使用 CPU0、CPU1、CPU2。每个 rx 队列都可以单独配置，一般建议设置成 “设备所在 NUMA 节点内所有 CPU”。RPS 的好处是灵活，不用重启驱动就能改；缺点是会引入额外的 IPI（处理器间中断），自己本身也会产生中断开销。所以在核数不多的小机器上，开 RPS 反而可能适得其反。

RFS（Receive Flow Steering）是 RPS 的进阶，它会根据应用进程当前运行的 CPU 来调整数据包投递目标，尽量让处理数据包的 CPU 和读取数据的应用进程在同一个核上，提升缓存命中率。RFS 需要配合 rps_sock_flow_entries 和 rps_flow_cnt 两个参数使用，配置相对繁琐，我在高并发缓存型业务上见过明显收益，通用的小流量场景就没必要上了。

4.3 NAPI 轮询与中断合并参数：控制中断频率的旋钮

前文提到 NAPI 的核心思想是“中断开启—批量轮询—中断关闭”，但对中断合并参数的调优，很多朋友不太熟悉。ethtool -c eth0 可以查看当前的 coalescing 配置：

bash复制ethtool -c eth0
Coalesce parameters for eth0:
rx-usecs: 8
rx-frames: 32

rx-usecs: 8 表示网卡收到第一个包后最多等 8 微秒再产生中断，这样能把这段时间内到达的后续包一并捎带上。rx-frames: 32 表示攒够 32 个帧再产生中断。这两个值组合起来决定中断触发频率。

常见的调优做法分两类场景。低延迟场景，比如高频交易、实时音视频，优先保证每个包都被尽快处理，rx-usecs 调到 1 甚至直接禁用合并，代价是 CPU 中断频率飙升。高吞吐场景，比如大数据传输、视频转码，延迟不是第一诉求，把 rx-usecs 调到 32 或 64 微秒，rx-frames 调到 128 或 256，中断频率大幅下降，CPU 有更多时间做批量处理。

注意：中断合并参数调大以后，一定要观测应用层延迟是否受影响。曾经有一个 RPC 框架，服务端网络处理用了默认的高吞吐配置，P99 延迟从 800 微秒涨到了 3 毫秒，排查到最后发现就是 rx-usecs 偏高导致接收延迟叠加。把该队列的 rx-usecs 调回 8，P99 延迟立刻回到 900 微秒以内。调参没有银弹，必须结合业务的真实延迟指标做验证。

网卡驱动层面还有一个重要参数是 buffer 大小，ethtool -g eth0 可以查看 RX 环形缓冲区的大小：

bash复制ethtool -g eth0
Ring parameters for eth0:
Pre-set maximums:
RX:             4096
RX Mini:        2048
RX Jumbo:       8160
TX:             4096
Current hardware settings:
RX:             1024
RX Mini:        1024
RX Jumbo:       1848
TX:             1024

如果流量突发性强，RX 环形缓冲区太小会导致丢包，丢包后协议栈的 TCP 重传又会产生额外的确认包和重传包，间接推高中断频率。有条件的情况下，把 RX 的 ring buffer 调大一些，比如 ethtool -G eth0 rx 4096，对突发流量有明显的缓冲效果。

4.4 升级驱动与固件：解决硬件层面的“无解”问题

软件配置都做完了，中断风暴还在，那就必须考虑硬件和固件的问题。有一个案例让我印象很深：某批新采购的服务器，同一型号的网卡，在同样配置的内核和同样的业务流量下，有三分之一出现反复的收包中断风暴，另外三分之二完全正常。一开始怀疑是配置文件差异，后来把正常和异常两台机器的网卡固件版本一对比，发现异常机器的固件版本明显偏旧。刷完固件后，问题全部消失。

硬件层面的排查建议按这个顺序来：先用 ethtool -i eth0 查看驱动版本和固件版本，确认和网卡厂商官方发布的最新版本是否一致；再到厂商官网查看更新日志，看是否有针对“中断异常”“丢包”“队列挂死”等问题的修复；最后在维护窗口内升级驱动或固件并做回归验证。

另一个常见的硬件相关因素是 PCIe 链路问题。lspci -vvv -s [设备地址] 可以查看网卡的 PCIe 链路状态，包括 LinkCap、LinkStatus、报错计数器。如果看到链路降速（比如从 8GT/s 降到 2.5GT/s）或者设备出现大量的 AER 错误，说明物理链路可能存在接触不良或信号完整性问题，这类问题会间接引发设备反复重试，表现在上层就是中断异常。

提示：升级固件有风险，必须在业务低峰期、有 console 访问和备份方案的前提下操作。千万不要在生产负载运行中直接刷固件，万一设备脱机，影响面可能是一整片业务。

5. 嵌入式 Linux 与虚拟机场景：中断风暴的“隐藏副本”

5.1 为什么嵌入式设备更容易踩坑

嵌入式 Linux 的场景和通用服务器不同，面临几个天然劣势：CPU 核数少、中断共享程度高、实时性要求苛刻。一个常见的例子是嵌入式设备使用 GPIO 模拟中断，外部传感器每秒触发多次电平变化，如果驱动在中断处理函数里做了耗时的操作，比如 I2C 读取或者 SPI 传输，整个系统的实时性就崩了。

嵌入式场景里，中断风暴的表现经常是“莫名卡顿”。设备看起来没死机，但按键响应慢、屏幕刷新卡顿、网络 ping 延迟忽高忽低。这类问题排查难度大，因为嵌入式环境里通常没有现成的监控工具，/proc/interrupts 存在，但很多精简内核没开对应的配置。

嵌入式优化的几个关键点。第一，严格限制中断处理函数里的工作，只做必要的数据读取和标志位设置，其他的推到 tasklet、workqueue 或者内核线程去做。第二，合理配置设备树中的 interrupt 属性，避免多个设备挂在同一根中断线上互相干扰。第三，评估是否真的需要高频中断，有些传感器可以用轮询方式替代中断，或者降低采样频率，中断密度降下来了，才对“风暴”有免疫力。

嵌入式环境还经常遇到系统 tick 和实时任务抢占的问题。默认的 CONFIG_HZ=100 或者 250 可能不够精确，有人图省事直接调成 1000，中断频率确实上去了，很多本不需要那么细粒度调度的场景被无谓唤醒，白白增加功耗和 CPU 占用。做实时性优化时，PREEMPT_RT 补丁其实比单纯调高 HZ 更值得优先考虑，它从内核调度层面保证了实时任务的响应时间，而不是靠高频时钟去“碰运气”。

5.2 虚拟机与容器环境：共享中断的连锁反应

虚拟机场景和实体机不同，一个物理核上可能同时跑多个虚拟 CPU，虚拟机的网卡中断最终都要落到宿主机上处理。VirtIO 网卡在虚拟机里看到的“中断分布”和宿主机实际的物理中断分布是两回事。当多个虚拟机同时在跑网络密集型业务时，宿主机上的中断风暴会波及所有虚拟机，表现为某些虚拟机网络性能突然下降，其他虚拟机也跟着受影响。

这种情况的排查要分两头看：在虚拟机里看 si 和 NET_RX，判断是不是自身业务量太大；在宿主机上看物理网卡的中断分配和 vCPU 的调度情况，判断是否存在主机层的中断挤占。如果物理网卡不支持 SRIOV，或者宿主机 CPU 核数不足，虚拟化叠加后中断合并和 NAPI 的行为会变得不可控，这其实是很多云主机网络性能不如物理机的一个重要原因。

容器环境里，共享宿主内核的网络协议栈，一个高 PPS 容器会把宿主机整个 NET_RX 软中断推到高位，其他容器的网络延迟跟着遭殃。解决方案是给高流量容器单独配置 CPU 和网卡队列，或者用 tc 做流量整形限制它的 PPS，以及把容器和宿主的关键进程做 CPU 隔离。

6. 常见问题速查与经验总结

6.1 中断风暴排查问题速查表

6.2 我在实际调优中的几条心得

这些经验其实不是一次两次换来的，是反复踩坑之后才固化下来的检查清单。第一，先保底再优化，不要一上来就动配置。中断风暴的排查，顺序永远是：看现象—采数据—锁范围—改配置—验证。跳步会很危险，尤其是你在生产环境里把中断亲和性改乱比不改还要命。第二，所有改动都要可回滚。改之前备份 /proc/irq/*/smp_affinity 的原始值，改完记录下来，方便出问题快速恢复。

第三，不要迷信“高配置”。很多时候机器配置越高，默认参数就越保守，性能反而上不去。我曾经在 128 核的机器上见过网卡只有 4 个队列，中断全部压在前 4 个核上，后面 100 多个核闲着看热闹。这种问题，配置再好的机器也白搭。

第四，监控是最后的防线，也是第一道的预警。把 /proc/interrupts、/proc/softirqs、mpstat -I CPU 的数据纳入监控系统，设置阈值和告警，不是为了事后排查，而是为了风暴刚露苗头时就能发现。某次线上事故，我们就是被监控平台的“CPU 软中断占比超过 40% 持续 10 分钟”告警推着去排查，才在业务受损之前解决了问题。从这个角度说，中断风暴真正可怕的不是它本身，而是你发现它的时候，业务已经抖了好一阵了。