/proc/interrupts是Linux系统中唯一可信的硬件中断统计视图，仅提供已注册逻辑IRQ号及其各CPU触发次数，不暴露物理引脚或电平状态；其首列为内核分配的逻辑ID（如42），虚拟化下IR-PCI-MSI等前缀表明编号与硬件解耦，末列设备名（如enp3s0f0）比IO-APIC描述更可靠，数值突增而无对应进程多因硬件抖动或驱动异常，需结合/proc/softirqs、trace-cmd耗时分析及smp_affinity_list亲和性验证交叉定位真实瓶颈。
/proc/interrupts就是你要的答案，没有更底层或更“具体”的硬件中断请求视图——内核不暴露物理引脚、电平跳变或芯片级 IRQ 线状态，只提供已注册、可统计的逻辑中断号（IRQ）及其触发次数。
怎么看懂 /proc/interrupts 里每一行的真实含义
执行 cat /proc/interrupts 后，关键不是数总数，而是拆解每行结构：
- 首列是 IRQ 编号（如
42），它只是内核分配的逻辑 ID，**不等于物理引脚号**；虚拟化下常见IR-PCI-MSI 32768这类前缀，说明用了中断重映射，编号和硬件完全解耦 - 中间各列对应 CPU0、CPU1… 的触发计数，数值非零 ≠ 设备在干活，启用 NAPI 或轮询（
ethtool -C eth0 rx off）后，硬中断计数归零但流量照常 - 末列是设备标识，最可靠的是具体名字（如
enp3s0f0、nvme0n1），而非IO-APIC 16这类控制器泛称；RES（重调度）、CAL（IPI）、TIMER属内核调度行为，不是硬件设备打来的
怎么快速定位网卡或 NVMe 这类关键设备的中断源
别扫全屏，用过滤+动态观察盯变化速率：
- 盯网卡：运行
watch -n 1 'grep -E "(enp|ens|eno|eth)" /proc/interrupts'，重点看某 CPU 列是否每秒涨几百/几千——其他核不动，就是单核堵了 - 盯 NVMe：用
grep nvme /proc/interrupts，若看到多行带nvme0n1q0、nvme0n1q1后缀，说明开了多队列；只有一行没后缀，大概率驱动没启用队列绑定 - 查 IRQ 绑定的 CPU：拿到 IRQ 号（如
grep enp3s0f0 /proc/interrupts | awk '{print $1}'），再查cat /proc/irq/42/smp_affinity_list，输出是十进制 CPU 编号（如0,2），安全可读
为什么不能只信 /proc/interrupts 的数字暴涨
数值突增但没进程在跑？八成不是负载高，而是硬件或驱动问题：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 网卡丢包重试、PCIe 设备误报、老 RAID 卡固件 bug 都会导致 IRQ 计数疯涨，但实际无有效数据流
-
/proc/interrupts只记触发次数，不反映 handler 耗时；卡顿抖动必须用trace-cmd record -e irq:irq_handler_entry -e irq:irq_handler_exit -T 5抓 delta 字段（纳秒级），超过100000（即 100μs）就得怀疑驱动在中断上下文里干了重活（比如 memcpy 大块内存） - 改了
smp_affinity_list没生效？先看/proc/irq/42/effective_affinity，如果和你写的不一致，说明irqbalance或内核自动管理正在覆盖
软中断和硬中断必须一起看，否则误判严重
/proc/interrupts 是硬中断入口计数，/proc/softirqs 才是真实工作量：
- 运行
cat /proc/softirqs | grep NET_RX，如果 CPU0 的值比 CPU1 高两个数量级，说明网络包全压在 CPU0 上，ksoftirqd/0 忙死，这不是高负载，是绑定失衡 - NET_RX 高但硬件中断计数很低？说明 NAPI 没生效，或者驱动把本该 defer 到 softirq 的工作塞进了硬中断 handler
- mpstat -P ALL 1 显示某核
%soft长期 >30%，再查对应 CPU 在/proc/softirqs中哪一列增长最快，才能锁定瓶颈类型（如SCHED高说明调度压力大，RCU高可能是锁竞争或 callback 堆积）
真正难的不是“怎么查”，而是查完之后怎么交叉验证：硬中断分布、软中断执行、handler 耗时、亲和性设置这四条线对不上，就一定有隐藏配置或驱动行为在干扰。
