iotop -o 必须加，因默认显示所有进程（含io%为0的sshd等），干扰判断；加-o后仅显示真实磁盘读写进程，快速定位高io“真凶”，是日常排查起点。
iotop -o 为什么必须加这个参数
不加 -o，iotop 默认会列出所有进程，包括那些几乎不读写磁盘的“安静”进程，比如 sshd、systemd，它们 IO% 常常显示为 0.00%，严重干扰判断。加了 -o 后只保留当前正在做真实磁盘读写的进程，一眼就能聚焦“真凶”。
常见错误现象：运行 sudo iotop 后满屏滚动却找不到高 IO 进程，其实是被大量空闲进程淹没了。
-
sudo iotop -o是日常排查的起点，不是可选项 - 如果发现某进程 IO% 突然飙到 90%+，但
top里 CPU 占用很低，别怀疑——这是典型 I/O 密集型行为，进程正卡在磁盘等待（D 状态），ps -o pid,comm,state -p <pid></pid>可验证 - 注意区分
IO>列（当前带宽占比）和DISK READ/WRITE列（实际 KB/s 数值），前者适合快速排序，后者用于判断吞吐是否真的超标
怎么按 IO% 排序并锁定罪魁进程
iotop 默认按 IO% 降序排列，但容易被干扰：比如某个进程 IO% 是 45%，另一个是 38%，看起来第一个最可疑；但如果前者是短时突发（如日志轮转），后者持续稳定在 35% 以上，后者才是真瓶颈。
实操建议：
- 启动时加
-d 2设置 2 秒刷新间隔：sudo iotop -o -d 2，观察连续 3–5 次输出中哪些进程的IO>值始终高位稳定 - 交互模式下按
r键可反转排序，方便对比读/写倾向；按← →键切换排序字段，比如切到WRITE列看谁在疯狂写入 - 若目标进程 PID 已知，直接用
-p <pid></pid>聚焦监控，避免被其他进程刷屏干扰 - 不要只盯单次峰值——I/O 瓶颈往往是持续性压力，不是瞬时抖动
IO% 高但硬盘没坏，下一步查什么
定位到高 IO 进程后，kill -9 是最差选择。真正要查的是它在读写什么、为什么这么读写。
关键动作：
- 用
lsof -p <pid></pid>查它打开了哪些文件，重点关注/var/log/下大日志、/tmp临时文件、数据库数据目录；如果看到大量.log或.tmp文件，大概率是日志未轮转或应用缓存失控 - 用
pidstat -d -p <pid> 1</pid>看每秒真实读写量（rKB/s/wKB/s）和请求次数（r/s/w/s）；如果r/s很高但rrqm/s（读请求合并数）极低，说明是大量小块随机读（如数据库索引扫描），不是磁盘慢，而是应用访问模式有问题 - 如果是 Java 或 Python 进程，检查是否启用了同步刷盘（如 Log4j 的
immediateFlush=true）、是否在循环中反复open/write/close同一文件
为什么 await 高但 %util 很低，iotop 却显示某进程 IO% 100%
这种情况很常见，也最容易误判。表面看磁盘设备没饱和（%util 可能才 20%），但 await 却高达 200ms，同时 iotop 显示某个进程 IO% 100%——这说明问题不在磁盘硬件，而在上层：可能是文件系统锁（如 XFS log stall）、内核 block layer 队列深度不足、或应用层频繁创建/删除小文件导致元数据操作阻塞。
此时 iotop 抓到的是“受害者”，不是“加害者”。真正该查的是：
-
iostat -x 1中的avgqu-sz：如果远大于 1（比如 15+），说明请求发得太猛，队列已堆积 -
cat /sys/block/sda/queue/scheduler看当前调度器是否匹配设备类型（NVMe 推荐kyber或mq-deadline，机械盘用deadline） -
find /path/to/mount -type f -size +100M -printf '%T@ %p\n' | sort -n | tail -5查最近修改的大文件，结合lsof看是否被同一进程反复覆盖
换更快的硬盘解决不了这类问题，得从应用行为或内核参数入手。
