直接看/proc/interrupts只能得到累计值，非实时频率；必须用watch -n 1动态观察某列每秒增量，如grep eth0 /proc/interrupts盯住数字跳变，每秒涨数千上万才属高频，多因硬件异常或驱动未启用napi。
直接看 /proc/interrupts 得到的是累计值，不是频率；真要看“每秒多少次”，必须用 watch -n 1 动态观察某列的跳变速度——否则数值再大也没意义。
怎么用 /proc/interrupts 看实时中断频率
/proc/interrupts 本身不带时间维度，只记录自启动以来各 CPU 上每个 IRQ 的触发总数。想判断是否高频，关键不是看绝对值，而是看单位时间内的增量。
- 执行
watch -n 1 'grep eth0 /proc/interrupts'（把eth0换成你实际网卡名，如enp0s3或ens33），盯住最后一列或某 CPU 列数字是否每秒涨几百、几千甚至上万 - 若某行中
CPU0列从1234567→1245678（+11111），而CPU1～CPU7几乎不动，说明中断没分发，不是设备真忙，是亲和性配置问题 - 别只扫一眼就下结论：有些异常是周期性尖峰（比如每 5 秒突增一次），
watch至少盯够 10 秒才能识别模式 - 对 NVMe 设备，改用
grep nvme /proc/interrupts，注意区分nvme0（控制器）和nvme0n1（块设备），后者通常不触发中断
为什么 vmstat 的 in 值和 /proc/interrupts 对不上
vmstat 1 输出的 in 列是每秒总中断次数（所有 CPU 合计），而 /proc/interrupts 是按 CPU 分列的原子累加值，两者统计口径完全不同。
-
in来自内核 tick 计数器快照，有采样延迟；/proc/interrupts是寄存器级原子读取，更精确但无时间戳 - 当
vmstat显示in > 5000/s且cs（上下文切换）同步飙升时，应立刻查/proc/interrupts定位具体 IRQ，而不是纠结数值差几百 -
vmstat -s | grep interrupts输出的是启动至今总中断数，无法反映瞬时压力，完全不能用于频率分析 -
in高 +r（运行队列）高 → 硬中断太多挤占 CPU 时间；in高 +b（阻塞进程）高 → 更可能是 I/O 设备响应慢，中断只是表象
NET_RX 软中断飙高说明什么
/proc/softirqs 中的 NET_RX 不等于硬件中断次数，它是内核收包后触发的延迟处理任务，每秒超 10 万次基本可断定网络路径异常。
- 执行
watch -n 1 'cat /proc/softirqs | grep -E "^(NET_RX|TIMER|SCHED):"'，重点看单核上数值是否线性飙升（比如 CPU0 的 NET_RX 从 1200000 → 1300000 → 1400000） -
NET_RX高但NET_TX很低 → 接收队列溢出、RPS 未启用、或驱动未走 NAPI 路径 -
TIMER和SCHED同步高 → 更可能是短时任务过多拖住调度器，未必是中断问题 - 别误读
HI:（hardirq）列——它只是硬中断上下文切换计数，不能代替/proc/interrupts查具体设备
怎么确认中断是不是全打在单个 CPU 上
90% 的“中断频率高”其实是“全压在 CPU0”，不是设备真那么忙。Linux 默认不会自动分散网卡中断，得靠 smp_affinity_list 或 RPS 配合。
- 先查网卡对应 IRQ：
grep eth0 /proc/interrupts | awk '{print $1}'（输出如45:） - 再查绑定情况：
cat /proc/irq/45/smp_affinity_list 2>/dev/null，若输出是0，说明只绑在 CPU0 - 对比
/proc/irq/45/effective_affinity，它反映当前实际生效的掩码，比smp_affinity_list更真实 - 如果
ethtool -l eth0显示Combined: 1，说明网卡只开了 1 个队列，此时调亲和性意义不大，得先运行sudo ethtool -L eth0 combined 4开多队列 - 修改前务必确认没被干扰：某些云环境或容器平台会锁死亲和性设置，
echo 0-3 > /proc/irq/45/smp_affinity_list可能静默失败
真正难的不是看到数值跳变，而是区分“高频”是设备能力不足、驱动缺陷，还是单纯配置没摊开——同一行里 CPU0 狂涨而其他核为 0，八成是后者；但若所有核都同步暴涨，就得查硬件信号质量或驱动日志了。
