优先选pidstat -d而非iotop，因其不依赖实时刷盘动作，能稳定采集/proc/pid/io统计，避免buffered i/o场景下“抓空”；支持非root权限监控自身进程，兼容cgroup v2容器环境，且输出聚焦rkb/s、wkb/s，干扰少、定位准。
直接用 pidstat -d 1，配合 pgrep -f 定向追踪，比 iotop -o 更稳、更准、更少漏进程。
为什么优先选 pidstat -d 而不是 iotop
很多人一上来就跑 iotop -o，结果终端空空如也——不是没 IO，是它默认只显示“此刻正在做 I/O”的进程，而很多数据库、日志服务采用 buffered I/O，写操作攒一批再刷盘，iotop 就容易“抓空”。pidstat -d 不依赖实时刷盘动作，只要内核记录了 I/O 统计（/proc/PID/io），它就能稳定采样。
-
iotop必须sudo才能看到用户进程，否则静默跳过，且在 cgroup v2 容器环境下可能聚合显示，看不出单个容器内哪个进程在捣鬼 -
pidstat -d即使非 root 也能看自己启动的进程（如当前终端起的java或python），权限更友好 -
pidstat -d 1输出字段明确：只盯rkB/s和wkB/s，其他列（比如%MEM）全是干扰项，不会误读
pidstat -d 的正确用法和常见错法
错法：只输 pidstat -d ——它执行完立刻退出，根本看不到动态变化；或输 pidstat -d 0 ——采样间隔为 0 会触发内核高频轮询，终端卡死甚至拖垮系统。
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
- 必须带正整数采样间隔：
pidstat -d 1（每秒刷新）、pidstat -d 5（5 秒一刷，适合观察趋势） - 监控指定进程时，用
pgrep -f获取 PID 最可靠：pidstat -d 1 -p "$(pgrep -f 'postgres.*-D')"，避免ps aux | grep postgres匹配到 pg_isready 或备份脚本 - 加
-l显示完整命令路径：pidstat -d -l 1，防止多个 Java 进程都只显示为java，分不清是哪个服务
数值怎么看才不被带偏
rkB/s 和 wkB/s 是瞬时速率（KB 每秒），不是累计值。数值忽高忽低（比如 0 → 18000 → 0 → 4200）非常正常，大概率是应用层用了 page cache + 周期性回写，不是磁盘故障。
- SATA SSD 实际持续写入超 15000 KB/s（≈15 MB/s）就接近瓶颈；NVMe 超 50000 KB/s（≈50 MB/s）基本满载
- 如果
rkB/s长期高于 0 且业务并无大量读操作，优先查日志轮转、逻辑备份、或异常缓存加载 - 别被
iostat的%util带节奏：%util > 80% 是信号，但更要结合await（平均等待毫秒）和avgqu-sz（平均队列深度）判断是否真卡住
怎么联动验证，避免单点误判
单看 IO 数值容易断章取义。比如某个 Java 进程 wkB/s 很高，但可能是 GC 触发大量对象落盘；或者 rkB/s 高，实则是内存不足被迫频繁 swap。
- 加
-r同时看内存：pidstat -d -r 1，观察 RSS 是否稳定 —— RSS 稳但rkB/s持续高位，才是真实业务读（如报表导出） - 加
-u同时看 CPU：pidstat -d -u 1，区分是 CPU 密集型卡顿（CPU 高 + IO 低）还是纯 IO 密集型（IO 高 + CPU 低） - 确认磁盘设备级压力：
iostat -dx 1看await是否持续 > 20ms，比%util更早暴露延迟问题
真正难的不是看到哪个进程在读写，而是判断它“该不该这么读写”——这需要结合业务逻辑、部署方式（容器 or 物理机）、以及 IO 模式（direct vs buffered）一起看。工具只是放大镜，不是诊断书。
