直接看/proc/interrupts可获中断触发次数，但仅凭总数易误判；需结合smp_affinity_list查绑定CPU、trace-cmd抓单次handler耗时（>100μs需警惕）、/proc/stat看总量趋势，三者对齐才能准确定位硬件异常、驱动bug或配置失当。
直接看 /proc/interrupts 就能知道谁在频繁打断 CPU，但光看总数容易误判——硬件异常、驱动 bug 或 NAPI 轮询关闭都会让数值失真。
查中断触发次数用 cat /proc/interrupts
这是最轻量、最可靠的起点，内核实时维护，不依赖额外工具。
- 每行首列是 IRQ 编号（如
42），后续各列对应 CPU0、CPU1… 的触发次数，最后一列是设备或控制器标识（如eth0、nvme0n1、IO-APIC） - 数值暴涨但没对应进程跑？大概率是硬件异常（网卡丢包重试、PCIe 设备误报）或驱动 bug，不是负载高
- 虚拟化环境里看到
IR-PCI-MSI或IR-IO-APIC前缀，说明用了中断重映射，IRQ 编号已和物理引脚解耦，不能按传统编号理解 - 某行全为 0 不代表设备没工作——启用
ethtool -C eth0 rx off tx off后，网卡可能切到 NAPI 轮询模式，中断计数归零但流量照常
定位中断绑定到哪个 CPU 用 cat /proc/irq/*/smp_affinity_list
中断默认分散，但单核被打满会导致延迟抖动；查亲和性是为了确认是否“堵在一条道上”。
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
- 别碰
smp_affinity（十六进制掩码），x86 和 ARM 位宽不同，写错直接导致中断不触发 -
smp_affinity_list输出的是十进制 CPU 编号（如0,2），人眼可读，也兼容所有架构 - 快速查网卡绑在哪：
grep eth0 /proc/interrupts | awk '{print $1}' | xargs -I{} sh -c 'echo {}:/proc/irq/{}/smp_affinity_list' | while read l; do echo "$l: $(cat ${l##*:} 2>/dev/null)"; done - 先看
/proc/irq/*/effective_affinity，如果它和smp_affinity_list不一致，说明被内核自动管理（比如 irqbalance 正在干预）
抓单次中断耗时用 trace-cmd record -e irq:irq_handler_entry -e irq:irq_handler_exit
/proc/interrupts 只有总量，卡顿或抖动必须看单次 handler 入口到出口的纳秒级耗时。
- 必须确认内核开启 ftrace：
grep CONFIG_IRQSOFF_TRACER /boot/config-$(uname -r)返回y或m - 抓 5 秒：
trace-cmd record -e irq:irq_handler_entry -e irq:irq_handler_exit -T 5 - 分析时盯
delta字段（单位纳秒），超过 100μs 就值得怀疑驱动做了太多事（比如在中断上下文里 memcpy 大块数据） - 别用
perf record -e irq:*——它不保证入口/出口配对，采样精度也不够，没法算真实 handler 耗时
看中断总量趋势用 grep 'intr ' /proc/stat
这个值是自启动以来所有中断的累计次数，适合观察长期增长斜率，辅助判断是否“越用越慢”。
- 输出形如
intr 123456789 123456 789012 ...，第一个数字是总中断数，后面是各 IRQ 的单独计数（顺序与/proc/interrupts行序一致） - 和
/proc/interrupts的区别在于：这里没有 CPU 分列，只有总数；但它是单一整数，适合写监控脚本做 delta 比较 - 注意它不包含软中断（
softirq），要看软中断得单独grep 'softirq ' /proc/stat - 如果总中断数增长远快于业务请求量，优先怀疑硬件故障或驱动未正确 ACK 中断
真正难的不是“怎么查”，而是把 /proc/interrupts 的数字、trace-cmd 的 delta、smp_affinity_list 的绑定结果三者对齐——比如发现 eth0 中断全打在 CPU0 上，且 delta 平均 150μs，那问题八成出在网卡驱动的中断处理逻辑里，而不是 IRQ 分配本身。
