/proc/interrupts 是查看中断统计最直接轻量的方式，仅反映各 CPU 上 IRQ 触发次数，不记录时间戳或调用栈；数值暴涨而无对应进程运行，多因硬件异常或驱动 bug。
查看当前中断统计用 /proc/interrupts
这是最直接、最轻量的方式，内核实时维护这个只读文件，反映每个 CPU 上各类中断（IRQ）的触发次数。它不记录时间戳或调用栈，只告诉你“谁被触发了多少次”。
常见错误现象：cat /proc/interrupts 输出里某列数值暴涨，但没对应进程在跑——大概率是硬件异常（比如网卡丢包重试、PCIe 设备误报中断）或驱动 bug。
- 每列代表一个 CPU，行首是 IRQ 编号（如
1是键盘，25可能是 NVMe），后面跟着设备名（如eth0、nvme0n1） - 虚拟化环境里看到
IR-PCI-MSI或IR-IO-APIC前缀，说明用了中断重映射，此时 IRQ 编号和物理引脚已解耦 - 数值为 0 不代表设备没工作——有些现代设备用 NAPI 或轮询模式绕过传统中断，比如启用
ethtool -C eth0 rx off tx off后网卡中断会锐减
查中断延迟和处理耗时用 trace-cmd + irq:irq_handler_entry
/proc/interrupts 只有总量，真要定位卡顿或抖动，得抓单次中断从触发到 handler 返回的完整路径。这时候必须用 ftrace，而 trace-cmd 是最顺手的封装。
使用场景：怀疑某个设备（比如 USB 声卡）导致音频断续，或 PCIe 设备响应延迟突增。
- 先确认内核开启 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字段——它是irq_handler_exit减irq_handler_entry的纳秒级差值，超过 100μs 就值得查驱动是否做了太多事 - 别用
perf record -e irq:*，它采样精度不够，且默认不记录 handler 入口/出口配对
查中断绑定 CPU 用 cat /proc/irq/*/smp_affinity_list
Linux 默认把中断分散到多个 CPU，但某些场景（如低延迟交易、DPDK）需要固定到特定核，否则 cache 抖动和迁移开销会吃掉性能。
容易踩的坑：直接写十六进制掩码到 smp_affinity（非 _list）易出错，因为不同架构位宽不同（x86 是 32/64 位，ARM 可能更宽），而 smp_affinity_list 统一输出十进制 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/*/effective_affinity，如果和smp_affinity_list不一致，说明有irqbalance或内核策略在干预 - 写入新绑定时，务必用
smp_affinity_list（如echo 0-1 > /proc/irq/42/smp_affinity_list），别碰老式smp_affinity
中断风暴时快速定位源头用 watch -n 1 'awk '"'"'{if(NR>1)sum+=$2}END{print sum}' /proc/interrupts'"'"'
当系统突然变慢、load 飙高、top 显示 %si（softirq）持续 30%+，八成是中断风暴。这时不能一条条数 /proc/interrupts，得先看总量变化趋势。
这个命令每秒算一次所有中断总和，比肉眼扫屏快得多；再结合前后两次输出差值，就能锁定爆发窗口。
- 如果总量每秒涨几万，立刻
grep -v "0$" /proc/interrupts找活跃 IRQ，再查对应设备：ls -l /sys/bus/pci/devices/*/irq 2>/dev/null | grep "42"（假设 IRQ 42 异常） - 注意区分硬中断（
%hi）和软中断（%si）——前者飙升说明硬件真在狂发信号，后者高可能是内核下半部积压，比如网卡收包太快但应用没及时 consume - 某些 BMC 或 IPMI 设备在故障时会以毫秒级频率刷中断，且不显示在
/proc/interrupts设备名列，得靠dmesg | tail -50看有没有IPMI: Spurious interrupt类提示
中断不是越少越好，而是要匹配负载特征；绑定 CPU、关中断合并、换 polling 模式这些操作，都得先确认瓶颈真在中断路径上，而不是内存带宽或锁竞争。
