发布于2026-08-15 阅读(0)
扫一扫,手机访问
必须用 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 可读。普通用户如果直接执行 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 下所有线程,不然一个 Ja va 进程底下几十个 TID 全摊开,根本没法看
• 进界面后按 Shift+P 可按 IO> 排序 —— 高值(如 >90%)代表进程卡在磁盘响应上,比带宽更早暴露瓶颈
• DISK WRITE 持续 >10MB/s 且 IO> >80%,基本可锁定为写入源;但若 IO> 高而带宽低(如 200KB/s),大概率是小文件高频刷盘或锁竞争,不是吞吐问题
iotop 不回答“写什么文件”,只告诉你“谁在提交 I/O”。立刻切到:
• sudo lsof -p :列出该进程打开的所有 fd,重点关注 REG 类型且带 w 权限的行
• sudo ls -l /proc/:直接看 fd 符号链接指向的路径,比 lsof 更底层、更少误判
• 如果 NAME 列末尾有 (deleted),说明文件已被 rm 但 fd 未关,磁盘空间不会释放
• 容器环境注意:PID 是宿主机视角,lsof 必须在宿主机执行,且容器不能用了 --pid=host 以外的 PID namespace 隔离
要是权限实在提不上去,iotop 基本就没法用了。这个时候还能拿来顶一顶的,主要就这几样:
• iostat -x 1:重点看 %util 和 await,先判断问题是不是卡在设备层面,但它没法继续往下追到具体进程
• pidstat -d 1:前提是得先知道 PID,而且在非 root 环境下,输出里的 kB_wr/s 可能并不准确(它依赖 /proc/PID/io)
• atop -d:有些发行版会预装,按 d 键可以切到磁盘视图,不过同样得有 root 权限,才能把完整进程名显示出来
• 至于 top 或 htop,别抱太大希望:它们本身不统计磁盘 I/O,iotop 里的 IO> 列,在 top 里压根就没有
真正麻烦的从来不是怎么看到高 IO 进程,而是看到之后发现它在写一个日志轮转中的临时文件、或正被 rsync --delete 扫描整个 /var —— 这些上下文信息,iotop 一行命令给不了,得靠 cat /proc/ 和业务逻辑交叉判断。
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
正版软件
正版软件
正版软件
正版软件
正版软件
1
2
3
4
5
6
7
8
9