直接看/proc/interrupts是最轻量可靠的起点，可获各IRQ在每核的触发次数及设备标识，但需结合smp_affinity_list查绑定CPU、trace-cmd抓单次handler耗时（>100μs需警惕）、/proc/stat看总量趋势三者对齐，才能准确定位硬件异常、驱动bug或配置失当。
直接看 /proc/interrupts 是最有效、最轻量的起点，它能告诉你哪些设备在频繁打断 CPU，但单看总数容易误判——硬件异常、驱动 bug 或 NAPI 轮询关闭都可能让数值失真。
查中断触发次数：定位高频中断源
运行：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
每行首列为 IRQ 编号（如 42），后续各列对应 CPU0、CPU1… 的触发次数，末列为设备标识（如 eth0、nvme0n1、IO-APIC）。
- 某一行数值持续暴涨，但无对应用户进程或网络/磁盘流量变化？大概率是硬件异常（如网卡丢包重试、PCIe 设备误报）或驱动缺陷
- 虚拟化环境中看到
IR-PCI-MSI或IR-IO-APIC前缀，说明启用了中断重映射，IRQ 编号已与物理引脚解耦，不能按传统编号理解 - 某行全为 0 并不意味设备空闲——例如执行
ethtool -C eth0 rx off tx off后，网卡可能切换至 NAPI 轮询模式，中断计数归零但流量照常
查中断绑定 CPU：确认是否“堵在一条道上”
运行：
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或逐个查看：cat /proc/irq/42/smp_affinity_list（输出为十进制 CPU 编号，如 0,2，人眼可读且跨架构兼容）。
- 若某 IRQ 只绑定单个 CPU（如仅 CPU0），而该核 softirq 或 %irq 占用长期超 70%，就容易引发延迟抖动
- 优先看
/proc/irq/42/effective_affinity，它反映当前实际生效的绑定；若与smp_affinity_list不一致，说明 irqbalance 或内核自动管理正在干预 - 避免直接写
smp_affinity（十六进制掩码），x86 和 ARM 位宽不同，写错会导致中断完全不触发
抓单次中断耗时：识别长 handler 引发的抖动
/proc/interrupts 只给总量，卡顿和微秒级抖动必须看单次 handler 从入口到出口的真实耗时。
- 先确认内核支持：
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 耗时计算
交叉验证趋势：结合 /proc/stat 看全局中断总量
运行：
grep intr /proc/stat输出形如 intr 123456789 123456 123456 ...，首字段为所有中断总次数，后续为各 IRQ 计数（与 /proc/interrupts 对应）。
- 对比多次采样差值，观察中断总量增长速率是否与业务节奏匹配；若突增却无负载变化，指向硬件或固件问题
- 将
/proc/interrupts高频 IRQ、smp_affinity_list绑定关系、trace-cmd中高 delta 值三者对齐，才能准确定位是硬件异常、驱动 bug 还是配置失当
