直接用sudo iotop -o -P，重点关注IO>和DISK WRITE两列，90%的狂写磁盘问题当场就能锁定；-o过滤静默进程，-P屏蔽线程干扰，IO>接近100%表明高频等待磁盘，哪怕DISK WRITE值小也极可疑。
直接用 sudo iotop -o -P，重点关注 IO> 和 DISK WRITE 两列，90% 的狂写磁盘问题当场就能锁定。
为什么必须加 -o 和 -P
默认运行 iotop 会混入大量静默进程和内核线程（比如 [kthreadd]、[migration/0]），真实写盘的业务进程被淹没在一堆 0.00B/s 里。
-o 表示只显示「此刻正在实际读写磁盘」的进程，不是刚写过、而是正在写；
-P 表示只显示进程（不展开线程），避免 Java、MySQL 等服务动辄上百线程分散注意力。
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
关键指标怎么看
IO> 列比带宽更敏感：值接近 100%，说明进程大部分时间卡在等磁盘响应上——哪怕 DISK WRITE 只有几 KB/s，也可能是高频小文件刷盘（如 DEBUG 日志轮转、数据库 WAL 写入）。
DISK WRITE 列反映真实写入速率，单位自动缩放（B/s、K/s、M/s）；持续 >10MB/s 就值得警惕。
顶部的 Actual DISK WRITE 远大于 Total DISK WRITE（例如 25MB/s vs 0.85MB/s），说明脏页堆积严重，内核马上要爆发式刷盘，磁盘延迟将飙升。
快速定位与验证操作
- 进界面后按 Shift+P，切换为按 IO> 降序排列，比默认排序更容易揪出“假低速、真高等待”的顽固写盘者
- 看到高 IO 进程别急着 kill，先用
lsof -p PID查它正往哪个文件写——是不是日志落到了慢盘或 NFS 上 - 对数据库进程（如 mysqld），结合
SHOW ENGINE INNODB STATUS看 Log sequence number 与 Last checkpoint 差值，判断是否因配置过小导致频繁刷盘 - 对 Java 进程，用
pidstat -d -p PID 1看累计写入量，确认是持续行为还是偶发峰值
脚本化采集防翻车
在远程或自动化场景中，必须用 -b（batch 模式）：sudo iotop -b -n 1 -o -P | awk '$11 ~ /^[0-9.]+$/ && $11 > 5 {print $1, $11, $12}'
其中 $11 是 IO> 值（新版 iotop 多在第 11 列），$12 是 COMMAND；
务必先运行 iotop --version 和 iotop -h 确认当前版本的列顺序，避免字段偏移导致漏报。
