必须用 sudo iotop -o -P：-o 过滤静默进程，-P 按进程聚合线程，sudo 获取 /proc/PID/io 权限；若内核无 taskstats 或权限不足则显示为空；批处理用 -b -n 1，替代方案为 pidstat -d。
直接用 iotop -o -P 看真正在刷盘的进程
绝大多数人卡在“为什么 iotop 一运行全是 0.00B/s 或空白”，根本原因不是命令写错，而是没加关键参数或权限不对。必须用 sudo iotop -o -P：
-
-o过滤掉静默进程——只显示当前有实际读写行为的进程，避免被刚启动但还没 IO 的服务干扰 -
-P关闭线程视图——同一进程多个线程（如 Java 应用）会分散在多行，-P强制按进程聚合，一眼看清哪个 PID 在吃磁盘 - 不加
sudo或非 root 用户执行，iotop拿不到 /proc/PID/io 数据，必然为空或报Kernel thread not supported
IO>（I/O 等待时间占比，>30% 就算高压力）、DISK READ/DISK WRITE（真实带宽）。按 Shift+P 切换按 IO> 排序，比默认按带宽更早发现高频小文件刷盘的“隐形杀手”。
查不到数据？先验证内核和权限是否就绪
iotop 不是“装完就能用”的工具，它依赖内核 taskstats 支持和 CAP_SYS_ADMIN 权限：
- 检查内核是否启用：
zcat /proc/config.gz 2>/dev/null | grep -i taskstats—— 若无输出，说明内核未编译该功能（常见于最小化安装的 CentOS/RHEL/AlmaLinux） - 确认权限：
sudo getcap /usr/bin/iotop，应返回/usr/bin/iotop cap_sys_admin+ep；若无，需手动授予权限：sudo setcap cap_sys_admin+ep /usr/bin/iotop - 普通用户即使加
sudo，若系统策略禁用sudo继承 capability，仍会失败——此时必须切 root 用户执行
iotop，但因内核缺失或权限链断裂，始终看不到真实 IO 数据。
脚本或容器里用 iotop -b -n 1 抓快照
交互式 iotop 在远程终端、CI/CD 或容器中容易卡住或无法操作，必须用批处理模式：
-
sudo iotop -b -n 1 -o -P——-b关闭交互，-n 1只采一次立即退出，避免阻塞流程 - 字段位置随版本变化：新版本（如 1.3+）
IO>在第 11 列，老版本可能在第 10 列；用iotop -h查列名，或先跑一次看表头再写awk - 典型过滤示例：
sudo iotop -b -n 1 -o -P | awk '$11 > 5 {print $1, $11, $12}'—— 提取IO>>5% 的活跃进程 PID、IO% 和命令名
-b 模式下不会自动刷新，也不能按 Shift+P 排序，所有排序和过滤必须靠后续管道完成。
当 iotop 失效时，用 pidstat -d 补位
iotop 依赖 cgroup 和 taskstats，某些容器环境（如旧版 Docker、systemd-nspawn）或内核配置受限时会失效。此时转向 pidstat：
-
sudo pidstat -d 1 5—— 每秒采样一次，共 5 次，显示各进程的kB_rd/s（每秒读 KB）、kB_wr/s（每秒写 KB） -
pidstat不依赖 taskstats，只要 /proc/PID/io 可读就能工作，兼容性更强 - 对比差异：
iotop显示实时瞬时值，pidstat默认统计自上次启动以来的累计值，加-d后才显示速率；首次运行结果不可信，建议至少采两次 - 要查单个进程详情：
sudo cat /proc/<code>PID/io，重点看read_bytes和write_bytes（真正落盘字节数），而非rchar/wchar（含 pagecache 的逻辑读写）
iotop 是第一响应工具，但不是唯一路径。复杂环境里，pidstat + /proc/PID/io 才是兜底方案。 
