异常中断需人工识别：查/proc/interrupts看分布，结合watch动态监控增量、/proc/stat总量校验、lsirq排序及dmesg日志交叉验证，再用trace-cmd抓单次handler耗时（>100μs需警惕），三者对齐才能准确定位硬件异常、驱动bug或配置失当。
没有“异常中断统计报表”这种现成东西——所谓异常，是靠对比、趋势和阈值人工识别出来的。
查 /proc/interrupts 看总量分布，但别只盯单个数字
直接 cat /proc/interrupts 是起点，但它只给累计值，不告诉你“是否异常”。关键看三点：
- 某行数值暴涨，但
ps aux --sort=-%cpu找不到对应高负载进程？大概率是硬件异常（比如网卡丢包重试）或驱动 bug，不是业务忙 - 同一设备（如
eth0）在 CPU0 上计数是 CPU1 的 100 倍？说明中断没均衡，可能触发抖动，不是总数高就是问题 - 看到
IR-PCI-MSI或IR-IO-APIC前缀？这是虚拟化/现代平台的中断重映射，IRQ 编号已和物理引脚解耦，不能按老经验猜硬件位置
用 watch -d 动态抓增量，比静态值更有说服力
静止的 /proc/interrupts 容易误判。真正要抓“异常”，得看每秒新增量：
- 运行
watch -d -n 1 'cat /proc/interrupts | grep eth0'，观察高亮跳变——如果某列每秒涨几百且持续 10 秒以上，就得查了 - 别只盯
eth0，也注意cascade、uhci_hcd、ahci这类模糊标识，它们背后可能是 USB 设备掉线或 SATA 控制器报错 - 配合
awk '{print $1, $2-$2_prev}'类脚本做差值计算更准，但watch -d已够快速初筛
交叉验证：/proc/stat + lsirq + dmesg 才算闭环
单靠 /proc/interrupts 容易漏判。必须三者对齐：
- 用
awk '/^intr/ {print $2}' /proc/stat拿全局中断总数，和/proc/interrupts各行加总对比——若差值大，说明有 arch_timer、ipi 这类不显式列在 /proc/interrupts 里的高频源 - 装
lsirq（sudo apt install linux-tools-common或yum install kernel-tools），跑sudo lsirq -s increment -n 5直接排序出增量 Top 5，比人眼扫/proc/interrupts快得多 - 立刻查
dmesg | tail -50 | grep -i "error\|warn\|irq"，很多硬件异常（如 PCIe AER 错误、NVMe controller reset）会在内核日志里留痕迹，比中断计数早几秒出现
别信 perf record -e irq:*，它根本没法定位 handler 耗时
想确认是不是中断处理函数太慢导致卡顿？perf record -e irq:* 是常见误区：
- 它不保证
irq_handler_entry和irq_handler_exit成对捕获，delta 计算不可靠 - 真实 handler 耗时必须用
trace-cmd record -e irq:irq_handler_entry -e irq:irq_handler_exit -T 5，然后看输出里delta字段（单位纳秒） - 超过
100μs就该怀疑驱动——比如在中断上下文里做了memcpy大内存块，这违反实时性原则 - 先确认内核开了 ftrace：
grep CONFIG_IRQSOFF_TRACER /boot/config-$(uname -r)输出得是y或m
中断异常从来不是一眼能看出来的数字游戏。最常被忽略的是：NAPI 关闭后 /proc/interrupts 计数归零，但设备仍在狂吞 CPU；或者 irqbalance 正在后台动态调亲和性，导致 smp_affinity_list 和 effective_affinity 不一致——这些细节不查，报表再“漂亮”也没用。
