必须通过watch监控/proc/interrupts每秒增量（如eth0行CPU0列每秒涨1111次）判断高频中断，而非依赖累计总数；同时交叉验证smp_affinity_list实际绑定、/proc/softirqs中NET_RX分布及mpstat %soft占比，四者同步收敛才表明中断真正均衡。
/proc/interrupts 本身不提供“走势”，只存累计值；要看出平衡变化趋势，必须靠单位时间增量观察+多维度交叉验证——否则看到的只是静态快照，容易把半年没重启的网卡误判为“中断风暴”。
盯住单位时间增量，而不是总数
/proc/interrupts 是自启动以来的累加计数，数值大≠频率高。真正反映“走势”的是每秒增长量。
- 执行 watch -n 1 'grep eth0 /proc/interrupts'（把 eth0 换成你的真实网卡名，如 enp5s0f0）
- 看某一行中某一列（比如 CPU0）是否持续线性上涨：1234567 → 1235678 → 1236789，每秒 +1111，才算有效高频
- 如果只有 CPU0 在涨，CPU1～CPU7 几乎不动，说明不是“总量高”，而是“分布失衡”
- 周期性尖峰（如每 5 秒突增一次）必须盯够 10 秒以上才能识别，watch 默认刷新太快反而容易漏
查 smp_affinity_list 确认绑定是否生效
中断队列数量 ≠ 实际分散效果。即使网卡启用了 8 个 RX 队列，若所有队列都绑在同一个 CPU 上，照样单核打满。
- 先用 grep enp5s0f0 /proc/interrupts | awk '{print $1}' 提取对应 IRQ 编号（如 47、48）
- 再查亲和性：cat /proc/irq/47/smp_affinity_list 和 cat /proc/irq/48/smp_affinity_list
- 输出应是类似 0,2 或 1,3 这样的十进制 CPU 列表；如果全是 0，说明没调
- 注意：/proc/irq/*/effective_affinity 才是实际生效值；若它和 smp_affinity_list 不一致，大概率是 irqbalance 在后台覆盖你改的配置
对比 /proc/softirqs 看软中断是否同步均衡
硬中断只是“敲门”，真正干活的是软中断。光看 /proc/interrupts 可能完全错过瓶颈。
- 运行 watch -n 1 'cat /proc/softirqs | grep NET_RX'
- 关注各 CPU 列数值差异：如果 CPU0 的 NET_RX 是其他核的 5 倍以上，且 mpstat -P ALL 1 显示该核 %soft 持续 >20%，就是软中断堆积
- NET_RX 每秒增长超 100000 次，基本说明 RPS 未启用、接收队列溢出，或驱动没走 NAPI 路径
- 注意：软中断不占 IRQ 编号，也不会出现在 /proc/interrupts 里，必须单独查
别信 irqbalance 自动管理，尤其在低延迟场景
很多人改完 smp_affinity_list 发现几秒后又变回去，八成是 irqbalance 在偷偷重写。
- 查状态：systemctl is-active irqbalance
- 强制停用：sudo systemctl stop irqbalance && sudo systemctl disable irqbalance
- 启用前确认必要性：虚拟化、桌面环境可留；但做金融交易、实时音视频、DPDK 或绑核部署时，它只会干扰你的确定性调度
- 它默认不感知 NUMA 拓扑，而网卡 IRQ 绑错 NUMA 节点（比如网卡插在 Node1，却绑到 Node0 的 CPU），会带来显著内存延迟
真实走势从来不是单点数字，而是 /proc/interrupts 增量、/proc/softirqs 分布、smp_affinity_list 实际值、mpstat 软中断占比这四条线是否同步收敛——任何一条脱节，就说明“平衡”只是假象。
