软中断（si）或硬中断（hi）过高会挤压用户进程执行时间，导致响应慢、延迟高、丢包；需先用top看各核si%/hi%是否异常（如单核si>15%），再用vmstat查in/cs飙升，结合/proc/softirqs观察NET_RX等增量速率，最后通过/proc/interrupts和smp_affinity确认中断是否绑定不均。
软中断（softirq）或硬中断（hi/si）占用 CPU 过高，会直接挤压用户进程和内核线程的执行时间，导致系统响应变慢、网络延迟升高、甚至丢包。分析的关键不是只看“CPU 使用率高”，而是定位“谁在频繁触发中断”以及“中断是否集中在单个 CPU 上”。
确认中断 CPU 占用是否异常
先用 top 查整体趋势：运行 top 后按 1 显示各核状态，重点关注 si%（softirq）和 hi%（hardirq）列。若某核 si% 持续 >15% 或达到 100%，就属于异常；而其他核 idle 很高，说明中断分布不均。
再用 vmstat 1 观察上下文切换（cs）和中断（in）：如果 in（interrupts/sec）数值远高于正常基线（如每秒几千上万），同时 cs 也同步飙升，说明中断引发大量调度开销。
定位是哪类软中断主导
查看 /proc/softirqs 获取历史累计值：
watch -d cat /proc/softirqs
重点关注几列的**变化速率**（单位时间内增量）：
- NET_RX：网络接收包触发，常见于高并发 HTTP/HTTPS 流量、DDoS、网卡未启用 RSS
- NET_TX：网络发送触发，多见于大文件上传、TCP 重传密集场景
- TIMER：内核定时器，若异常飙升，可能有大量短周期 timer（如某些监控 agent 频繁轮询）
- RCU：读写锁同步，常与内核模块加载、频繁进程创建销毁有关
例如：连续观察 2 秒，NET_RX 值从 12456789 跳到 12461234，即 2 秒内增长约 4500 次 → 平均每秒 2250 次，已属高频，需进一步排查网卡行为。
检查中断是否绑定不均
Linux 默认常把所有网卡中断路由到 CPU 0，容易造成单核瓶颈。查当前中断分布：
cat /proc/interrupts | grep -E "(NET|eth|enp|igb|ixgbe)"
观察各列数字（对应 CPU0、CPU1…），若只有第一列数字巨大、其余几乎为 0，就是典型单核压爆。
进一步确认该中断号的亲和性设置：
cat /proc/irq/<em>IRQ_NUM</em>/smp_affinity
返回值是十六进制掩码（如 1 表示仅 CPU0，3 表示 CPU0+CPU1）。若掩码过窄，可手动扩展：
echo 0xffff > /proc/irq/<em>IRQ_NUM</em>/smp_affinity
（注意：需 root 权限，且部分驱动要求重启网卡生效）
关联网卡与驱动行为
中断过高往往源于网卡收包压力。检查：
- 是否启用了 RSS（Receive Side Scaling）：
ethtool -l eth0查看当前队列数；ethtool -L eth0 rx N可设为 CPU 数量 - 是否使用了 NAPI：现代网卡基本默认开启，可通过
cat /proc/net/snmp | grep -A1 Tcp辅助判断（NAPI 启用后，中断频率会显著低于轮询模式） - 是否存在错误包：
ethtool -S eth0 | grep -i "err\|drop\|over"，大量 rx_missed_errors 或 tx_aborted_errors 可能引发重复中断
若确认是流量型问题，还可临时用 tcpdump -i eth0 -c 100 抓包，观察是否有异常连接（如 SYN 泛洪、小包风暴）。
