高频中断需看/proc/interrupts每秒增量而非累计值，如eth0 1秒增1111次才算高频；应结合watch监控、smp_affinity绑定、RPS启用及MSI-X向量数综合排查。
怎么看/proc/interrupts里中断是否真在高频触发
单看cat /proc/interrupts输出的累计值没意义，关键得看出“每秒涨多少”。比如某行eth0的计数从 1234567 变成 1235678，1秒内涨了 1111 次，才算高频；如果只涨 3 次，大概率是正常流量。
实操建议：
- 用
watch -n 1 'grep eth0 /proc/interrupts'锁定网卡行，盯着最后一列数字跳变——别只扫一眼就下结论 - 注意 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 未启用；TIMER和SCHED同步高 → 更可能是调度器被大量短时任务拖住，未必是中断问题 - 别误读
HI:（hardirq）列——它只是硬中断上下文切换计数，不能代替/proc/interrupts看具体设备
为什么vmstat的in列和/proc/interrupts对不上
vmstat 1 输出的 in 是每秒总中断次数（含所有 CPU），而 /proc/interrupts 是各 CPU 分列的累计值。两者单位、统计维度、甚至采样时机都不同——in 是内核 tick 计数器快照，/proc/interrupts 是原子累加寄存器读取。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
实操建议：
- 当
vmstat显示in持续 > 5000/s，且cs也同步飙升，优先查/proc/interrupts找具体 IRQ，而不是纠结数值差几百 -
in高 +r高 → 硬中断太多导致 CPU 来不及跑用户任务；in高 +b高 → 更可能是 I/O 设备响应慢，中断只是表象 - 不要用
vmstat -s的“interrupts”总数做分析——它只是一次性累计，无法反映瞬时压力
中断频率异常时，第一个该查的不是驱动，而是亲和性设置
90% 的“中断频率高”实际是“全打到一个 CPU 上”，不是设备真那么忙。Linux 默认不会自动把网卡中断分散到多核，得靠 smp_affinity 或 RPS 配合。
实操建议：
- 先确认当前绑定：找
eth0对应的 IRQ 号（grep eth0 /proc/interrupts | awk '{print $1}'），再查cat /proc/irq/IRQ号/smp_affinity_list - 若输出是
0，说明只绑 CPU0；想分到 CPU0–3，写入echo 0-3 > /proc/irq/（需 root）IRQ号/smp_affinity_list - 注意：改完要配合启用 RPS，否则软中断仍集中在原 CPU ——
echo f > /proc/sys/net/core/rps_cpu_mask（8 核系统）
真实排查中，最容易被跳过的环节是验证 MSI-X 向量数量和确认 RPS 是否生效。这两步不做，调再多参数都是白搭。
