Linux查看进程中断，pidstat -u 5使用详解

本文澄清了一个常见误区：`pidstat -u 5` 并不能用于查看或分析系统中断，它仅统计进程在用户态和内核态的CPU时间消耗（%usr/%system），而中断（IRQ/softirq）属于内核中断子系统的底层行为，与进程级统计不在同一抽象层面；若需诊断中断相关问题——如某进程是否引发网卡硬中断飙升或软中断压垮ksoftirqd——必须转向`/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 被压垮），应组合使用：

• /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 统计，连中断栈帧都看不见。

今天关于《Linux查看进程中断，pidstat -u 5使用详解》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于Linux的内容请关注golang学习网公众号！