Linux如何查看具体的进程所产生的软硬件中断

pidstat -u 5无法查看进程引发的中断，它仅统计%usr/%system CPU时间，不采集IRQ或softirq数据；真正追踪需用/proc/interrupts、/proc/softirqs或trace-cmd等内核级工具。

Linux里没有“进程产生的中断”这种东西——中断是硬件或内核子系统触发的，pidstat、top、ps这类进程级工具根本看不到中断向量、IRQ编号或软中断队列。想归因到某个进程，得换思路：不是“谁发了中断”，而是“谁让中断变多/变慢”。

为什么 pidstat -u 5 看不到中断来源

pidstat -u 5 能看到的，其实只是进程跑在用户态和内核态上的 CPU 时间，也就是 %usr 和 %system。至于中断计数，它不采；IRQ 关联，它不做；softirq 的执行上下文，它同样不会记录。所以，哪怕你看到 %system 很高，背后的原因也未必只有一种：可能是系统调用卡住了，可能是锁竞争上来了，可能是页错误变多了，也可能是进程一次次被软中断调度器抢占。问题就在这里——仅靠它，根本分不清 NET_RX 到底是 nginx 在收包触发的，还是 dpdk 应用在持续轮询。

• pidstat 输出里永远不会出现 INTR、IRQ、softirq 字段
• 加 -w 看上下文切换、加 -d 看 I/O，也只是间接线索，不是中断本身
• 误以为 pidstat -u 5 能替代 cat /proc/interrupts，等于拿温度计去测电压——工具不在同一层

怎么判断某个进程是否加剧了中断负载

真正要查“某进程是否导致中断飙升”，得从设备行为反推：它是否让网卡持续收包？是否频繁触发磁盘 I/O？是否绑定了 ksoftirqd？

• 查该进程是否在处理网络流量：ss -tulpn | grep $(pgrep -f your_process)，如果监听端口且 cat /proc/softirqs | grep NET_RX 某 CPU 列同步猛涨，就是强相关
• 查是否引发大量磁盘中断：用 iotop -p $(pgrep -f your_process) 看 I/O rate，再对比 grep nvme /proc/interrupts 或 grep ata /proc/interrupts 是否同步跳变
• 看它是否绑定了软中断线程：ps -eLf | grep ksoftirqd | grep -E "(CPU[0-9]|$(pgrep -f your_process))"，若发现 ksoftirqd/0 的 comm 和你的进程共用 tid，说明它正在消耗该核的 softirq 处理能力

trace-cmd 是唯一能关联进程与中断 handler 的方式

只有 trace-cmd 能抓到中断 handler 入口，并通过调用栈回溯到触发它的上下文——但这不是“进程发中断”，而是“中断 handler 执行时，哪个进程刚被调度出去/正在睡眠”。

• 先确认内核支持：grep CONFIG_IRQSOFF_TRACER /boot/config-$(uname -r) 必须返回 y 或 m
• 只追踪特定进程关联的中断入口：trace-cmd record -e irq:irq_handler_entry -g -p $(pgrep -f your_process) -T 3
• 分析时重点看 comm 字段（当前进程名）和 backtrace，如果栈里有 net_rx_action → igb_poll → schedule，说明网卡收包后调度了你的进程
• 注意：perf record -e irq:* 不可靠——入口/出口事件不配对，delta 字段算不准，别用

容易被忽略的关键点

别把中断理解成进程里的“子任务”——它本质上是异步事件。无论是硬中断号（IRQ），还是软中断类型（比如 NET_RX），都不存在和进程 PID 一一对应的映射关系。所谓“某个进程把中断打高了”，说到底，往往是它触发了设备侧的行为，比如持续调用 recv()，让网卡一直收发数据；又或者它把 CPU 吃得太满，结果导致 ksoftirqd 调度被拖慢，软中断只能越积越多。真想把问题查清楚，光盯着 ps 远远不够，必须把视角切到 /proc/interrupts、/proc/softirqs 和 trace-cmd 这三层，少看一层都不行。