直接看 /proc/interrupts 可知各 irq 在 cpu0、cpu1 等核心上的累计处理次数，但需结合 watch -n 1 'grep eth0 /proc/interrupts' 观察实时增量分布，并用 /proc/irq/n/smp_affinity_list 验证绑定关系及 trace-cmd 检测单次 handler 耗时（>100μs 需警惕），才能准确判断中断是否真被均衡分发与高效处理。
直接看 /proc/interrupts 就能知道每个 CPU 核心处理了哪些中断，但仅靠它无法确认“中断是否真被均匀分发”——必须配合亲和性检查和动态验证，否则看到的只是历史累计值，不是实时负载分布。
怎么看 /proc/interrupts 里各 CPU 列的实际含义
/proc/interrupts 每行对应一个 IRQ 编号，后续各列是该 IRQ 在 CPU0、CPU1… 上被处理的总次数。关键不是绝对数值，而是同一行内各列的相对增长速度：
- 执行
watch -n 1 'grep eth0 /proc/interrupts'，观察几秒——如果只有CPU0列数字猛涨，其他列几乎不动，说明该网卡中断全压在单核上 - 数值为 0 不代表设备没工作：启用
ethtool -C eth0 rx off后，网卡切 NAPI 轮询模式，中断计数归零但流量照常 - 虚拟化环境里看到
IR-PCI-MSI或IR-IO-APIC前缀，IRQ 编号已与物理引脚解耦，不能按传统编号反推硬件位置
怎么确认某个 IRQ 实际绑在哪些 CPU 上
别碰 smp_affinity（十六进制掩码），x86 和 ARM 位宽不同，写错会导致中断不触发；用 smp_affinity_list 更安全：
- 先查 IRQ 号：
grep eth0 /proc/interrupts | awk '{print $1}' | tr -d ':' - 再查绑定：
cat /proc/irq/42/smp_affinity_list（把 42 换成你的真实 IRQ 号），输出类似0,2表示只分发到 CPU0 和 CPU2 - 如果
/proc/irq/42/effective_affinity和smp_affinity_list不一致，说明irqbalance正在覆盖你的设置 - 某些设备（如 BMC、老 RAID 卡）固件锁定 IRQ，
echo 0,2 > /proc/irq/42/smp_affinity_list会报Operation not permitted，得先ls -l /proc/irq/42/确认文件存在
怎么验证中断分布是否真生效了
写完 smp_affinity_list 后不验证，等于没做。验证必须回看 /proc/interrupts 的实时增量：
- 启动监控：
watch -d -n 1 'grep eth0 /proc/interrupts'，盯住各 CPU 列是否同步增长 - 若仍只有单列跳变，先停掉
irqbalance：sudo systemctl stop irqbalance && sudo systemctl disable irqbalance - NUMA 架构下，优先绑定到与网卡直连的 CPU 节点：
lspci -vv -s $(ethtool -i eth0 | grep 'bus-info' | awk '{print $2}') | grep NUMA查节点号，再绑定 - 注意软中断干扰：
cat /proc/softirqs中NET_RX若在某 CPU 上远高于其他核，说明硬中断虽分散，但软中断处理没跟上，仍是单点瓶颈
真正难的不是查到数据，而是区分“中断计数高”和“中断处理拖慢系统”——前者可能是正常流量，后者往往藏在 trace-cmd 抓到的单次 handler 耗时里（>100μs 就危险），而这个步骤，90% 的人会跳过。
