磁盘i/o过高需按四步排查：先用top和iostat确认真实i/o瓶颈；再通过lsblk、df定位高负载磁盘及挂载点；接着用iotop、pidstat找出高io进程与线程；最后用lsof、strace等分析其具体读写行为。
磁盘I/O过高通常不是孤立现象，而是系统负载失衡的外在表现。关键在于快速确认是否真为I/O瓶颈，并层层聚焦到具体设备和进程，避免在CPU或内存问题上浪费时间。
第一步：确认是否存在真实I/O瓶颈
先看整体等待情况，再查磁盘利用率：
- 运行 top，观察右上角 %wa（iowait） 是否持续高于15%～20%，同时 %us 和 %sy 较低——这是I/O等待的典型信号
- 用 iostat -x 2 检查各磁盘的 %util：持续 ≥80% 表示设备已饱和；await > 50ms 说明请求排队严重，不只是忙，更是响应慢
- 注意区分：如果多个磁盘 %util 都低，但 %wa 很高，可能是内核预读（readahead）或内存回收触发的隐式IO，需结合 vmstat 1 观察 pgpgin/pgpgout 和 pgmajfault
第二步：定位压力集中的磁盘与挂载点
iostat 输出中找出 %util 或 await 最高的 Device（如 nvme0n1、sdb），然后确认它对应哪个业务路径：
- 执行 lsblk 或 df -h，将设备名映射到挂载目录（如 /var/lib/mysql、/data/logs）
- 用 cat /proc/mounts | grep sdb 查看挂载参数，留意是否启用了 noatime 或 barrier=0 等影响IO行为的选项
- 若为云盘（如 Alibaba Cloud 的 cloud_ssd），还需登录控制台查看云监控中的“实际IOPS”和“吞吐量”，比对是否已达规格上限
第三步：找出消耗IO最多的进程和线程
优先使用实时性强、权限要求低的工具：
- sudo iotop -o：只显示当前有IO活动的进程，按 DISK READ/WRITE 排序，重点关注 IO> 列（I/O等待时间占比）高的进程
- 补充验证：pidstat -d 1 可输出每个进程的 kB_rd/s 和 kB_wr/s，适合脚本化采集或后台记录
- 若需深入到线程级（例如MySQL单个慢查询线程打满IO），可用 ps -T -p
-o pid,tid,%cpu,%mem,comm 结合 iotop -p过滤
第四步：分析高IO进程的具体行为
光知道是哪个进程不够，要弄清它在读写什么、为什么频繁：
- 用 lsof -p
查看该进程打开的文件，重点找大文件、日志文件、临时文件（如 /tmp/#sql_*、/var/log/app/*.log） - 检查是否在刷脏页：MySQL 可查 SHOW ENGINE INNODB STATUSG 中的 LOG 和 FILE I/O 段；postgresql 查 pg_stat_bgwriter
- 观察系统调用：strace -p
-e trace=read,write,fsync,pwrite64 -s 32 2>&1 | head -20 快速捕捉近期IO操作目标 - 若为日志类进程，检查日志级别（如 log4j 的 DEBUG）、轮转配置（logrotate 是否失效）、是否同步刷盘（sync=True）