必须用 sudo iotop -o -P，否则看到的全是 0——因内核硬限制普通用户无权读取/proc/PID/io，sudo iotop -o -P 过滤静默进程与线程，聚焦真实I/O行为，再结合lsof -p定位具体文件。
必须用 sudo iotop -o -P，否则看到的全是 0 —— 普通用户无权读取 /proc/PID/io，这是内核硬限制，不是权限没配对。
为什么普通用户跑 iotop 显示全为 0
Linux 内核从 2.6.20 起把进程级 I/O 统计（/proc/PID/io）设为 root-only。普通用户执行 cat /proc/1/io 会直接报 Permission denied；iotop 依赖这个文件，拿不到数据就只能填 0。
即使加了 -u $USER 或 sudo -u nobody iotop，只要没 CAP_SYS_ADMIN 能力，所有 DISK READ/DISK WRITE 列都恒为 0。
验证方式：运行 sudo cat /proc/1/io | grep read_bytes 能看到数字，不加 sudo 就失败。
sudo iotop -o -P 是唯一靠谱起点
这个组合过滤掉静默进程和线程干扰，只显示当前真正在块设备上读写的用户态进程：
• -o（--only）：跳过空闲状态进程，比如 sshd、systemd 这类没发起 I/O 的，避免被淹没
• -P（--processes）：合并同 PID 下所有线程，不然一个 Java 进程底下几十个 TID 全摊开，根本没法看
• 进界面后按 Shift+P 可按 IO> 排序 —— 高值（如 >90%）代表进程卡在磁盘响应上，比带宽更早暴露瓶颈
• DISK WRITE 持续 >10MB/s 且 IO> >80%，基本可锁定为写入源；但若 IO> 高而带宽低（如 200KB/s），大概率是小文件高频刷盘或锁竞争，不是吞吐问题
看到高 IO 进程后，下一步必须查它在写哪个文件
iotop 不回答“写什么文件”，只告诉你“谁在提交 I/O”。立刻切到：
• sudo lsof -p <pid></pid>：列出该进程打开的所有 fd，重点关注 REG 类型且带 w 权限的行
• sudo ls -l /proc/<pid>/fd/</pid>：直接看 fd 符号链接指向的路径，比 lsof 更底层、更少误判
• 如果 NAME 列末尾有 (deleted)，说明文件已被 rm 但 fd 未关，磁盘空间不会释放
• 容器环境注意：PID 是宿主机视角，lsof 必须在宿主机执行，且容器不能用了 --pid=host 以外的 PID namespace 隔离
替代方案：没 root 权限时只能退到设备级
如果实在不能提权，iotop 就不可用。此时唯一能用的是：
• iostat -x 1：看 %util 和 await，确认是不是设备级瓶颈，但无法定位进程
• pidstat -d 1：需提前知道 PID，且输出里的 kB_wr/s 在非 root 下可能不准（依赖 /proc/PID/io）
• atop -d：部分发行版预装，按 d 键进磁盘视图，但同样需要 root 才能显示完整进程名
• 别指望 top 或 htop：它们不统计磁盘 I/O，iotop 的 IO> 列在 top 里根本不存在
真正麻烦的从来不是怎么看到高 IO 进程，而是看到之后发现它在写一个日志轮转中的临时文件、或正被 rsync --delete 扫描整个 /var —— 这些上下文信息，iotop 一行命令给不了，得靠 cat /proc/<pid>/cmdline</pid> 和业务逻辑交叉判断。
