pidstat -u 5 仅显示进程级cpu时间分布（%usr/%system），不统计中断次数或来源；真正查中断需用/proc/interrupts、/proc/softirqs或perf等内核级工具。
pidstat -u 5 不能查看系统中断，它只显示进程级 CPU 时间分布（%usr/%system），不涉及中断计数或来源。 真正要查“进程引发的中断”，得换工具——pidstat 本身不采集中断向量、IRQ 或软中断（softirq）数据，这是内核中断子系统层面的事，和进程统计不在同一抽象层。
为什么 pidstat -u 5 不反映中断？
pidstat -u 输出的 %system 是进程在内核态执行的时间总和，包含系统调用、页错误处理、锁竞争等，但不区分是否由硬件中断触发。比如一个进程频繁读磁盘，可能引发大量 I/O 中断，但 pidstat 只看到它占用了高 %system，看不到背后是 ata_piix 还是 nvme 的 IRQ 在猛跳。
-
pidstat -u 5中的5是采样间隔（秒），不是“每 5 秒一次中断统计” - 它不会输出
INTR、IRQ、softirq、timer等字段 - 即使加
-w（上下文切换）或-d（I/O），也仅间接关联中断，不等于中断本身
真正能看进程相关中断的替代命令
若你怀疑某个进程导致中断飙升（如网卡硬中断被某用户进程绑定、ksoftirqd 被压垮），应组合使用：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
-
/proc/interrupts：查看每个 CPU 上各 IRQ 的累计次数，配合grep锁定设备（如eth0、nvme0），再用cat /proc/irq/*/smp_affinity_list看中断亲和性 -
cat /proc/softirqs：观察NET_RX、NET_TX、HI、TIMER等软中断计数变化，用watch -n 1 'cat /proc/softirqs'对比差值 -
perf record -e irq:irq_handler_entry -g -p $(pgrep -f your_process)：只有当你明确想追踪某进程是否触发了特定中断 handler 时才用，但实际中极少直接命中（中断 handler 运行在 softirq 上下文，不属于用户进程）
pidstat -u 5 的真实用途和常见误用
它适合快速定位“谁在吃 CPU”，尤其是区分用户态和内核态开销。例如：
- 看到某 Java 进程
%usr很低、%system接近 100%，说明它卡在系统调用里（如epoll_wait、futex、read），不是中断问题，而是同步阻塞或锁争用 - 若
%system高且伴随pidstat -w中nvcswch/s（非自愿切换）飙升，更可能是 CPU 调度压力大，而非中断本身 - 误以为
pidstat -u 5能替代cat /proc/interrupts—— 它们解决的是完全不同的问题域
真正要归因“进程 → 中断”，必须跳出进程视角，进到中断控制器（APIC/IOAPIC）、驱动 IRQ 处理逻辑、以及软中断调度队列这一层。而 pidstat 停留在 task_struct 统计，连中断栈帧都看不见。
