sudo iotop -op是最准、最轻量的实时io进程定位入口，只显示当前正提交到块设备的读写进程，单位kib/s或mib/s，不统计缓存操作；重点看io%而非disk read/write数值，持续>90%表示进程卡在磁盘响应上。

直接用 iotop -o 看正在干活的进程

这不是“可能在读写”，而是**当前正提交到块设备的实时 IO 流量**，单位是 KiB/s 或 MiB/s。它不统计缓存内操作，只反映真实磁盘吞吐。

• sudo iotop -o 是最准、最轻量的入口：过滤掉所有 idle 线程，只留真正有读写动作的条目
• 加 -P（即 sudo iotop -oP）强制按进程聚合，避免 Java/Python 多线程应用拆成十几行干扰判断
• 别信 DISK READ/DISK WRITE 列数值本身——重点看 IO%：持续 > 90% 表示进程卡在等待磁盘响应，不是它写得多，而是存储慢或锁住
• 容器里跑 iotop 大概率报 Kernel does not support process I/O accounting，因为默认没开启 CONFIG_TASK_IO_ACCOUNTING，得切回宿主机查

pidstat -d 1 更适合脚本化监控

如果你需要把 IO 数据喂进 Prometheus 或写进日志，pidstat 比 iotop 更可靠：输出结构固定、无交互、不依赖终端尺寸。

PyCharm 2026.2.0.1 Linux版

PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。

下载

• 必须带刷新间隔，例如 pidstat -d 1；光写 pidstat -d 只输出一次就退出，起不到监控作用
• 关键字段只有两个：rkB/s（每秒读 KB 数）、wkB/s（每秒写 KB 数），其他列如 %MEM 或 UID 和 IO 无关，纯属干扰项
• 用 pgrep 动态取 PID 比手动 ps aux | grep 安全：比如 pidstat -d 2 -p "$(pgrep -f 'redis-server')"，避免匹配到旧残留进程
• 非 root 用户执行会静默跳过受权限限制的进程（如 systemd、内核线程），不会报错，但数据不全——这点容易被忽略

别把 ps 的 D 状态当成“正在读写”

ps 输出里 STAT 列为 D，只代表进程处于不可中断睡眠态，**正在等 IO 完成**，但不等于它此刻有数据在流动。

• ps -eo pid,comm,state,pcpu,wchan --sort=-pcpu | grep ' D ' 能筛出疑似卡住的进程，但 wchan 字段才告诉你它卡在哪（比如 wait_event 或 nvme_queue_rq）
• 要确认是不是真在读写，得立刻查 /proc/<pid>/io</pid>：如果 read_bytes 和 write_bytes 长时间不动，而状态又是 D，基本是底层驱动或硬件卡死，不是应用层问题
• 某些 RAID 卡驱动 bug 会导致假 D 状态，不能一看到 D 就断定磁盘慢——得结合 iostat -x 1 的 await 和 %util 交叉验证

iostat -x 1 告诉你“IO 是否真的慢”，而不是“谁在读写”

它和 iotop 是互补关系：一个管设备，一个管进程。单独看任一个都容易误判。

• %util 接近 100% ≠ 所有进程都在等 IO —— 可能只是单个 dd 进程占满带宽，其他进程根本没机会排队
• 真正危险的是 await 持续 > 50ms，尤其是 r_await 或 w_await 单独飙升，这时再回头用 iotop -oP 锁定对应读/写大户
• avgqu-sz（平均队列长度）比 %util 更早暴露瓶颈：HDD 上 > 2、SSD 上 > 1 就说明请求已在排队，哪怕 %util 还不到 70%
• 用 iostat -xk 1 /dev/sdb 可聚焦单盘，避免 NVMe 和 SATA 混在一起看花眼；加 -p ALL 能看到 LVM 逻辑卷的实际负载

真正麻烦的从来不是“怎么看到 IO”，而是看到之后——那个 WRITE 高的进程，到底在写哪个文件？iotop 不回答这个问题，lsof -p <pid></pid> 和 ls -l /proc/<pid>/fd/</pid> 才是下一步必须跟上的动作。