Linux怎么查看系统的中断频率 Linux性能分析之软中断详解

Linux怎么查看系统的中断频率 Linux性能分析之软中断详解

排查系统性能时，中断频率是个绕不开的指标。但怎么判断中断是不是真的“高”了？这里有个关键提醒：看/proc/interrupts里的每秒增量，而不是那个静态的累计值。 比如，如果eth0这一行在1秒内增加了1111次，那才叫高频；如果只涨了3次，大概率只是正常流量，不必紧张。

怎么看/proc/interrupts里中断是否真在高频触发

直接cat /proc/interrupts看到的数字是累计值，意义不大。真正的门道在于观察它“每秒涨多少”。举个例子，如果eth0的计数从1234567跳到了1235678，意味着1秒内触发了1111次中断，这才算得上高频事件。如果只涨了3次，那基本可以判定是正常流量，无需过度干预。

具体操作时，可以把握这几个要点：

• 动态监控是关键：使用命令 watch -n 1 'grep eth0 /proc/interrupts' 锁定你的网卡行，重点观察最后一列数字的跳变幅度。千万别扫一眼就下结论。
• 关注CPU分布：仔细看各CPU列的数值。如果只有CPU0在疯狂增长，其他核心几乎不动，那问题很可能不是中断频率太高，而是中断绑定不均衡，全压到一个核心上了。
• 结合硬件能力判断：设备配置本身可能就是瓶颈。比如，给万兆网卡只配了单个MSI中断向量，那eth0行的数值必然暴涨。动手前，先通过ls /sys/class/net/eth0/device/msi_irqs/看看它到底有几个IRQ，再评估这个数量是否合理。

/proc/softirqs里哪几列最值得盯

在软中断的世界里，NET_RX、TIMER和SCHED这三列是风暴预警的头号指标，尤其是NET_RX。需要明确的是，它反映的不是硬件中断次数，而是内核收包后的延迟处理任务。一旦它的每秒增长超过10万次，基本上就可以断定网络路径上出了问题。

具体可以这么操作：

• 锁定核心指标：执行 watch -n 1 'cat /proc/softirqs | grep -E "^(NET_RX|TIMER|SCHED):"'，观察这些数值是否在单个核心上线性飙升。
• 对比分析找线索：如果NET_RX很高但NET_TX很低，可能是接收队列溢出了，或者RPS（Receive Packet Steering）没有启用。如果TIMER和SCHED同时飙高，那更可能是调度器被大量短时任务拖住了，问题根源未必在中断本身。
• 避免常见误读：别把HI:（hardirq）列当成硬件中断的替代指标。它只是硬中断上下文切换的计数，要了解具体哪个设备在“搞事情”，还得回去看/proc/interrupts。

为什么vmstat的in列和/proc/interrupts对不上

这其实是个典型的“鸡同鸭讲”。vmstat 1输出的in列，是系统每秒发生的总中断次数（聚合了所有CPU），而/proc/interrupts显示的是每个CPU分开统计的累计值。两者的单位、统计维度，甚至采样时机都完全不同——in来自内核tick计数器的快照，而/proc/interrupts是直接读取原子累加寄存器的值。

面对这种差异，正确的思路是：

• 关注趋势，而非绝对数值：当vmstat显示in持续高于5000/秒，并且上下文切换cs也同步飙升时，优先做的是去/proc/interrupts里定位具体的IRQ号，而不是纠结为什么两个数值对不上几百的差额。
• 结合其他指标解读：如果in高的同时r（就绪队列长度）也高，说明硬中断太多，CPU忙不过来处理用户任务。如果in高伴随着b（阻塞进程数）高，那更可能是I/O设备响应慢，中断频发只是这个根本问题的表象。
• 选对工具：不要用vmstat -s输出的那个“interrupts”总数来做实时分析，那只是一个开机以来的累计值，根本无法反映系统瞬时的压力状态。

中断频率异常时，第一个该查的不是驱动，而是亲和性设置

经验表明，九成所谓的“中断频率高”案例，真相其实是“所有中断都打到了同一个CPU上”，设备本身可能并没忙到那个程度。Linux内核默认并不会自动把网卡中断分散到多个核心，这事儿得靠手动设置smp_affinity或者配合RPS来完成。

排查时，建议按这个顺序来：

• 先确认现状：找到eth0对应的IRQ号（grep eth0 /proc/interrupts | awk '{print $1}'），然后查看它的亲和性设置：cat /proc/irq//smp_affinity_list。
• 再进行调整：如果输出是0，说明中断只绑在了CPU0上。想把它分散到CPU0到CPU3，可以（以root权限）执行：echo 0-3 > /proc/irq//smp_affinity_list。
• 别忘了软中断：改完硬中断亲和性，必须配合启用RPS，否则网络软中断还是会集中在原来的CPU上。对于8核系统，可以设置：echo f > /proc/sys/net/core/rps_cpu_mask。

话说回来，在实际排查中，最容易被人跳过的一步，就是验证MSI-X向量的数量，以及确认RPS是否真正生效。 这两步基础工作不做，后面调再多内核参数，很可能都是白费力气。