直接运行iotop看不到写磁盘进程，因默认显示所有进程（含静默态和内核线程），且普通用户无权访问/proc/PID/io导致DISK WRITE全为0；需sudo iotop -o -P：-o仅显示当前真实I/O进程，-P按进程聚合避免线程干扰。
为什么直接跑 iotop 看不到写磁盘的进程
因为默认模式下 iotop 会列出所有进程（包括内核线程和静默进程），DISK WRITE 列全是 0.00 B/s，根本找不到真正在写的进程。这不是命令错了，而是没触发它的“活跃过滤”逻辑——内核只在进程真正发起读写时才更新统计，静默状态不计入。
sudo iotop -o -P 是最可靠的起点
这个组合能立刻筛出用户态进程中正在写磁盘的那几个，避免被 [kthreadd]、[rcu_gp] 这类内核线程干扰：
-
-o：只显示此刻有实际 I/O 行为的进程（不是“可能写”，是“正在写”） -
-P：强制按进程聚合，不展开线程（比如一个java进程底下几十个 TID，-P合并成一行） - 必须用
sudo：普通用户访问/proc/PID/io权限被拒，所有列恒为 0 - 进界面后按
Shift+P可切换按IO>排序——有些进程带宽不高（如高频小文件刷日志），但IO>能飙到 95%，这才是卡顿根源
看到高 DISK WRITE 后别急着 kill
高写入量不等于异常，得结合上下文判断：
- 查
mysqld：运行mysql -e "SHOW ENGINE INNODB STATUS\G" | grep -A 5 "Log sequence"，看 checkpoint 是否频繁；差值过大说明innodb_log_file_size太小 - 查
rsync或tar：执行cat /proc/<pid>/cmdline | tr '\0' ' '</pid>，确认是不是误操作备份了整个/ - 查
java进程：如果SWAPIN和IO>同时高，先看free -h和vmstat 1的si/so，大概率是内存不足触发 swap，磁盘写只是副作用
脚本化抓取时字段偏移容易错
sudo iotop -b -n 1 -o -P 输出的列顺序因版本而异，老版本 IO> 在第 10 列，新版本（1.3+）在第 11 列：
- 先运行
iotop --version确认版本 - 用
iotop -h查当前列定义，再写awk提取，例如：sudo iotop -b -n 1 -o -P | awk 'NR>3 && $11 > 5 {print $1, $11, $12}' - 加
-k固定单位为 KB/s，避免自动缩放导致解析失败 - 顶部的
Actual DISK WRITE和Total DISK WRITE差值大（比如前者 25MB/s，后者 0.8MB/s），说明脏页堆积严重，内核即将爆发刷盘——这时iotop显示的只是“冰山一角”，得立刻配合iostat -x 1看%util和await
