iotop 必须以 root 权限运行，否则因无权读取 /proc/[pid]/io 而所有 I/O 列显示为 0；其默认速率基于 rchar/wchar（含缓存），真实磁盘吞吐需看 read_bytes/write_bytes。
iotop 必须用 root 运行，否则所有 I/O 列都是 0
普通用户执行 iotop 时，DISK READ 和 DISK WRITE 全显示为 0，IO% 也恒为 0 —— 这不是 bug，是内核强制限制：非特权用户无法读取 /proc/[pid]/io，而 iotop 完全依赖这个接口。
- 验证方式：
cat /proc/1/io会提示Permission denied；加sudo cat /proc/1/io就能正常输出 - 别试
sudo -u nobody iotop或加-u $USER参数——只要没CAP_SYS_ADMIN能力，照样全零 - 容器里默认不可用：Docker 不继承宿主机的
CONFIG_TASK_IO_ACCOUNTING=y，得换sysdig -c topfiles_bytes或直接进宿主机查
真正反映“硬盘读写量”的字段只有 read_bytes/write_bytes
iotop 默认显示的速率（B/s、M/s）其实是 rchar/wchar，统计的是进程调用 read(2)/write(2) 的总字节数，含 page cache 命中、管道、伪设备（如 /dev/zero）——它不等于硬盘真实吞吐。
- 要定位“谁真在刷盘”，必须看
read_bytes和write_bytes：只计内核向块设备发起的实际读写请求字节数 - 手动查：
cat /proc/1234/io | grep read_bytes，输出形如read_bytes: 1234567890，单位字节 - 差值才是真实磁盘读量：比如 10 秒前是 100MB，现在是 150MB，那这 10 秒就真从硬盘读了 50MB
-
pidstat -d 1的rkB/s和wkB/s列就是基于read_bytes/write_bytes算的，比iotop更贴近物理层
快速筛选高 IO 进程：iotop -oP 和 pidstat -d 1
别让干扰信息拖慢判断——iotop 默认把线程（TID）和进程（PID）混排，pidstat 默认每秒只打一次快照，都不够干净。
-
sudo iotop -oP -d 2：-o只显示当前有 I/O 的进程，-P只列进程不列线程，-d 2每 2 秒刷新，一眼看到mysqld、rsync这类主进程 -
pidstat -d 1 3：每秒采样一次，共 3 次，输出带时间戳的rkB/s、wkB/s、%MEM，适合脚本解析或对比趋势 - 注意
IO%含义：iotop里是“等待 I/O 的时间占比”，>90% 表示进程卡在磁盘响应上，未必是它写得多，可能是存储慢或锁竞争 - 如果
DISK WRITE>10MB/s 且IO%>80%，基本可锁定为瓶颈源；但若IO%高而带宽低（如 1MB/s），大概率是随机小 IO 或延迟问题
看到高 IO 进程后，下一步必须查它在读写哪个文件
iotop 和 pidstat 都只告诉你“谁在 IO”，不回答“IO 的是什么”。不立刻切过去，排查就停在半路。
- 用
lsof -p 1234查该 PID 打开的所有文件，重点关注REG（普通文件）、MAP（内存映射）、DEL（已删但仍被占用的文件） - 更精准的实时追踪：
sysdig -p "%12s %6r %6w %s" -c fdbytes by fd.type=file，直接按文件路径聚合读写字节数 - 别信
vmstat的bi/bo：单位是 512 字节块，含 swap，不分设备也不分进程，纯宏观参考 - 真要存历史数据？自己写脚本周期性抓
/proc/[pid]/io—— 内核不保存 IO 时间序列，所有“历史”都得你主动采集
