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 这三层，缺一不可。
