Linux pidstat 怎么区分 CPU 忙和 I/O 等待：进程时间、上下文切换与复测方法

线上服务突然变慢时，CPU 使用率高并不等于进程一直在计算。先用 pidstat 对目标 PID 连续采样，再把 CPU 时间、块设备 I/O 延迟和上下文切换放在同一个时间窗口里看，通常能很快分出“算得忙”还是“等资源”。

先把“变慢”固定成一个采样窗口

排查前先记下进程 PID、发生时间和复现动作。不要只执行一次命令就截图，因为单次输出是累计值或瞬时值混在一起，无法看出变化速度。下面以 PID 1842 为例，先看进程级 CPU：

pidstat -p 1842 -u 1 5

连续五秒的结果里，重点看 %usr、%system、%CPU 和 Command。如果 %CPU 在每个采样点都明显升高，才有理由继续追 CPU；若只有一个点跳高，先扩大采样窗口。

用 CPU 时间增长判断是否真的在计算

pidstat -u 报告的是采样期间的 CPU 使用情况。用户态时间高，通常意味着应用本身在执行计算；内核态时间高，则要继续看系统调用、网络、文件或锁相关路径。这里的结论是“哪一类时间在增长”，不是“某一个字段高就一定是根因”。

pidstat -p 1842 -u -t 1 10

加上 -t 后可以观察线程。若总进程 CPU 不高，但某一线程持续占用，说明平均值把问题稀释了；若许多线程同时出现中等 CPU，又伴随频繁切换，则应把锁竞争和调度压力纳入检查。

内核文档中的 /proc//stat 还提供 utime 与 stime 等累计字段。它们适合在需要自建采样器时做差分，不适合拿一个绝对值直接比较两台机器。

把 I/O 等待从 CPU 忙里分出来

对同一 PID 再采样任务切换和块设备 I/O 延迟：

pidstat -p 1842 -w -d 1 10

-w 展示 cswch/s 与 nvcswch/s，-d 展示任务的读写活动和 iodelay。其中 iodelay 是块 I/O 延迟，包含等待同步块 I/O 完成以及换入块 I/O 的时间。CPU 使用率低而 iodelay 连续上升时，更像是等待存储或换入，而不是算力不够。

这个判断仍然需要和设备侧指标对照，例如同一时间查看对应磁盘的队列、吞吐和 await。进程级延迟高而设备并不忙，可能是单个文件、网络文件系统或进程自身的访问模式；不要直接把它写成“磁盘满了”。

上下文切换只能当证据链的一环

主动放弃 CPU 的 voluntary 切换，常见于线程阻塞等待资源；被迫让出 CPU 的 nonvoluntary 切换，则更接近时间片耗尽或调度竞争。通过 pidstat -w 观察两者的变化方向，比单看总切换数更有用。

grep -E 'voluntary_ctxt_switches|nonvoluntary_ctxt_switches' /proc/1842/status

如果 voluntary 切换和 I/O 延迟一起上升，先沿着文件、块设备或锁等待检查；如果 nonvoluntary 切换上升且 CPU 已接近配额，再检查同机竞争进程、CPU 亲和性和容器配额。两种切换都高时，不要急着改优先级，先确认采样期间是否发生了真实流量变化。

改动后怎样做一次可回退复测

一次只改一个变量。例如先恢复并发度，再重复同样的请求数量和采样窗口；不要同时调整 CPU 配额、线程数和磁盘参数，否则即使变快也无法知道是哪项改动起效。

1. 保存改动前五到十个采样点，记录 %CPU、iodelay、cswch/s 和 nvcswch/s。
2. 执行一个可重复的业务动作，等待指标回到稳定区间。
3. 用相同 PID 采样；若进程已重启，记录新 PID，不要把两段数据拼在一起。
4. 若延迟或错误率变差，立即恢复唯一改动，再重复同一复测。

验收看趋势，不看某个漂亮的平均值：CPU 忙的场景应有可解释的 CPU 时间增长；I/O 等待场景应能在 iodelay 或设备侧等待中找到对应证据；修复后至少要在相同负载下重复一次。

常见问题

pidstat 的 %CPU 为什么和 top 不一样？

采样间隔、线程展示方式、CPU 总数归一化和进程是否刚启动都会造成差异。两者不要混用不同时间段的结果，先固定间隔与 PID。

iodelay 高就一定是磁盘坏了吗？

不一定。它表示任务等待块 I/O 或换入的时间，还可能受到文件系统、网络块设备和访问模式影响。应与设备和内核日志一起复核。

上下文切换多是不是一定有锁竞争？

不是。I/O 阻塞、管道、条件变量和调度竞争都可能增加切换。只有在切换变化与锁等待、CPU 饱和或 I/O 延迟同时出现时，才值得继续沿该方向定位。

结语

区分 CPU 忙和 I/O 等待，关键不是背字段名称，而是让同一 PID 在同一采样窗口里留下可比较的变化：先看 CPU 时间，再看 iodelay，最后用上下文切换补充方向。改动后按同样负载复测，结论才站得住。