pidstat -d 显示进程实时IO读写速度，关键字段是rkB/s（每秒读取KB）和wkB/s（每秒写入KB），需指定间隔如pidstat -d 1，不带参数则只输出一次，-d 0可能导致终端卡死。
pidstat -d 怎么看进程的实时IO读写速度
直接用 pidstat -d 1 就能每秒刷新一次所有进程的磁盘IO，关键字段是 rkB/s（每秒读取千字节数）和 wkB/s（每秒写入千字节数）。这两个值就是你真正要盯的“IO读写速度”。
常见错误是只输 pidstat -d 不带间隔参数——命令执行完立刻退出，压根看不到动态变化；也不要用 pidstat -d 0，这会让采样频率失控，可能卡死终端。
-
rkB/s和wkB/s是瞬时速率，单位是 KB/s，不是累计量 - 如果某进程
rkB/s长期稳定在 20000+，说明它正在持续读取约 20MB/s，已接近 SATA SSD 的吞吐瓶颈 - 注意：
pidstat -d默认只显示活跃IO的进程，静默状态的进程不会出现在输出里
监控指定进程（比如 Python 服务）的 IO 时为什么总找不到 PID
别先 ps aux | grep python 再手动抄 PID——多实例、参数含空格、启动路径不同都会导致漏匹配或抄错。正确做法是用 pgrep 精准定位再喂给 pidstat：
pidstat -d 2 -p "$(pgrep -f 'gunicorn.*wsgi')"
这里 pgrep -f 匹配完整命令行，比只用 pgrep gunicorn 更可靠；但要注意：$() 返回多个 PID 时会以空格拼接，而 pidstat -p 原生支持多 PID 输入，无需额外处理。
- 如果
pgrep -f匹配太宽（比如匹配到日志轮转脚本），加-u $USER限定用户 - 非 root 用户查 systemd 或内核线程会权限拒绝，报错类似
Permission denied，这不是命令写错，是权限问题 -
pidstat -p后跟不存在的 PID 不会报错，而是直接跳过——所以建议先kill -0 $PID 2>/dev/null && echo ok验证存活
pidstat -d 输出里 %MEM 和 IO 没关系，别被字段位置误导
pidstat -d 默认不显示内存列，但如果你写了 pidstat -dr，输出里会出现 %MEM、RSS 这些内存字段——它们和磁盘IO完全无关，只是共用同一行输出而已。IO 读写速度只看 rkB/s 和 wkB/s，其他列都是干扰项。
更易混淆的是：有些教程把 pidstat -u（CPU）和 -d（IO）混着讲，误让人以为 %CPU 高就代表 IO 忙——其实 CPU 高可能是计算密集型，IO 高却可能 CPU 很闲（比如大文件拷贝时 CPU 在等磁盘响应）。
-
pidstat -d不依赖 /proc 文件系统以外的数据源，只要进程没被 freezer cgroup 挂起，数据就可信 - 容器内进程的 IO 统计受 cgroup v1/v2 限制，
pidstat -d显示的是宿主机视角的 IO，不是容器限制后的值 - 如果发现
rkB/s数值忽高忽低（比如 0 → 15000 → 0 → 8000），大概率是应用用了 buffered I/O + page cache，实际落盘不连续
和 iotop、iostat 比，pidstat -d 适合什么场景
当你已经知道目标进程（或能快速定位到它），且只需要它的 IO 速率，pidstat -d 最轻量、最稳定。它不依赖 TTY、不抢终端控制权、输出格式适合管道后续处理（比如 pidstat -d 1 | awk '$7 > 10000 {print $NF}' 抓写入超 10MB/s 的命令）。
相比之下：iotop 是交互式、需 root、默认按 IO% 排序，适合“盲扫”谁在狂刷磁盘；iostat -x 只能看到设备级（如 sda）吞吐，无法下钻到进程维度。
- 生产环境批量采集时，
pidstat -d -h 1 60（-h表示单行输出）比iotop -b -n 1更可靠，后者在无活跃 IO 时可能卡住 -
pidstat -d的采样精度受限于内核 jiffies（通常 10ms 级），对亚毫秒级 IO 尖峰不敏感，别拿它测 NVMe 的微突发 - 如果进程 fork 出子进程并继承 fd，子进程的 IO 会计入父进程统计——这是内核行为，不是 pidstat bug
