磁盘突然飙升却找不到明显的写入者时，iotop 把吞吐直接指回那个在捣乱的进程。系统级工具只给症状——await 高、util 打满——不给嫌疑人：五十个进程共享磁盘，平均值平等地怪每一个。终结调查的永远是按进程的问题——谁、多少、何时开始——iotop 从内核计数器实时回答，应用藏都没处藏。
把它放在系统级视图旁边，而不是代替。iostat 或 vmstat 说磁盘是瓶颈，iotop 点名是谁造成的。两者合起来把存储悬案压成两条命令：确认资源，锁定消费者。
逐个进程的计数器
iotop 从内核读每个进程的 IO，于是实时读写速率能对应到一个 pid，而不是一个说不清来源的负载均值。加 -o 只显示真正在做 IO 的进程，一眼看清。默认视图读写分开，还带 swap-in 百分比，把真吃磁盘的和仅仅在场的分开——DISK READ 高、写零的是在扫，写高的在产； throttle、迁移还是杀，取决于这个区分。
注意计数器量的到底是什么：穿过 IO 层的按进程字节，含还没落盘的缓冲写。进程写速率巨大、磁盘看着却闲（页缓存吸收），或速率平平、磁盘打满（大量小同步写），都可能。iotop 跟设备 util 一起读：进程侧定罪加设备侧饱和才是完整画面，任一半单独都误导。
看到谁在扫盘
按带宽排序，那个罪魁就现形了，无论是日志囤积、索引器还是失控备份。跟住这个 pid，就能定位到确切的进程（往往还有文件），再动手不迟。惯犯名单：debug 级别没轮转的日志、排在高峰的重建索引、同盘读写备份、坏镜像上循环解包的容器层。修法各不同——轮转、改期、分开、清理——杀进程治标，病因明天定时再来。
动手前把 pid 解析到完整上下文：命令行、工作目录、lsof 看开文件、父进程。一个烧写的 java 进程背后可能是一个 PID 命名空间里的十个应用；修要修对那一个。先定罪后动手——每个以遗憾收场的存储 war story 都跳过了第一步。
先看再动
iotop 只观察、不改变任何东西，所以你可以在决定节制、迁移或停掉之前先把元凶查清楚。再配 strace 或 lsof 打到这个 pid，把文件和系统调用一并钉死。组合是决定性的：iotop 说 18412 进程写 400MB/s，lsof 说写进一个膨胀的日志文件，strace 显示 4KB 的 O_APPEND 写——诊断完毕；修法（日志级别、轮转、异步 appender）不言自明，不用开会争。
健康时录基线，故障时对比才有意义。平时某天 iotop -b -n 60 落文件五分钟，就是这台机器的"正常"数字：平时谁领跑、多少速率算寻常。没有它，每次 spike 都像史无前例；有了它，多数 incident 几秒归类：“又是 indexer，提前一小时”。
把 iotop 批输出和系统监控同一时段的曲线放一起看，进程侧和设备侧互相印证，结论才站得住。单看任何一边，都可能把相关当因果。
告警阈值按基线设，而不是拍脑袋，基线之外的 spike 才值得半夜起床。
把 Top 写入者的变化趋势也画出来，渐变比突变更早暴露问题。
基线文件要标清楚采集条件：采集时段、业务负载水位、iotop 的采样间隔与累计方式，否则下次对比就是拿苹果比橙子。建议每周固定一个低峰窗口复采一次，覆盖掉业务自然增长带来的漂移；复采后把新旧两份排名并排 diff，只看名次变化超过三位的进程，逐个确认是业务上线还是异常冒头，再决定跟进还是放行。确认结论也要回写基线备注。
坏掉的样子
最经典的元故障是权限盲：没特权跑，iotop 进程细节全问号，别用户的进程直接不显示——而真凶恰跑在别用户下，隐形到底。一开始就带够特权（root 或对应 capabilities），不然工具开脱的恰是你看不见的进程。无特权 iotop “什么都没查到”，只代表你自己的进程没事。
第二种是突发 IO 的采样幻觉：一分钟暴力一秒的进程，5 秒平均看着无辜，1 秒平均看着有罪，反之亦然。数字和症状对不上就换 delay 档；“过去一小时谁伤的盘"问累计总量（-a）不问瞬时速率。聚合方式对，问题才对；默认聚合只答它自己假设的那个问题。
快速验证
非交互地抓谁在做 IO，带上下文：
iotop -b -n 5 -o -d 2 | head -n 30
pid=$(iotop -b -n 1 -o | awk 'NR>5 {print $1}' | head -n 1); ls -l /proc/$pid/exe; cat /proc/$pid/cmdline | tr '\0' ' '
iostat -x 1 3 | grep -E "Device|sd|nvme"
batch 抓排名不占终端，pid 解析点名头号写者的二进制，iostat 确认设备侧真打满。
