磁盘i/o雪崩本质是资源耗尽致进程卡d状态，需四步排查：一确认瓶颈（iostat/vmstat看%util、await、队列等）；二定位高io进程（iotop/pidstat）；三分析文件行为（lsof/proc/fd）；四判断io模式。
磁盘读写性能低下引发的雪崩，本质是 I/O 资源耗尽导致大量进程卡在不可中断睡眠（D 状态），进而拖垮负载、阻塞应用请求、触发级联超时。排查不能只盯“慢”，而要快速锁定“谁在压垮磁盘”以及“为什么压垮”。以下是实战中验证有效的四步闭环排查路径。
一、确认是否真为磁盘层瓶颈
先排除误判：CPU 低、内存足、但系统卡顿、接口延迟飙升、wa（iowait）持续高于 50%、load average 远超 CPU 核数，且出现大量 D 状态进程，才是典型信号。
- 运行
iostat -xz 1，重点看：
– %util ≥ 95%（尤其连续多秒）→ 设备饱和；
– await 显著高于 svctm（例如 await=42ms，svctm=0.12ms）→ 队列严重堆积；
– r/s 或 w/s 异常高（如机械盘随机写超 150，SSD 写超 10k）→ IOPS 打满；
– avgqu-sz > 2（队列长度）→ 请求排队等待。 - 同步执行
vmstat 1，观察 b（blocked）列是否持续非零，以及 io（bi/bo）数值是否远高于历史基线。
二、定位高 IO 进程与行为特征
仅知道“磁盘忙”没用，必须锁定具体进程，并区分它是狂写日志、刷数据库页，还是删文件不释放句柄。
- 用
iotop -oP查看实时占用最高的进程（IO% 和 DISK WRITE 最关键）；若无 iotop，可用pidstat -d 1替代。 - 拿到 PID 后，立刻查它在操作哪些文件：
–lsof -p PID | grep -E '(REG|DIR)' | sort -k7 -rn | head -10（按文件大小倒序）；
–ls -l /proc/PID/fd/ 2>/dev/null | grep -E '\.log$|/data|/tmp'（快速定位日志或数据目录）。 - 判断 IO 模式：
– 若iostat -x 1中 avgqu-sz 高 + 单次 IO 尺寸（avgrq-sz）小文件随机写（如数据库 WAL、频繁 fsync 的日志）；
– 若 wkB/s 极高但 w/s 不高 → 多为大块顺序写（如归档、备份、日志轮转）。
三、深挖根因：从文件到系统配置
找到进程后，需判断是业务逻辑问题、配置不当，还是底层异常。
- 检查该进程是否在写已删除但仍被占用的文件（常见于日志轮转未 reload）：
–lsof | grep deleted，若输出中含该 PID 对应的大文件，说明空间未释放，持续写入黑洞。 - 查看其 IO 调度策略是否匹配硬件：
–cat /sys/block/sda/queue/scheduler；
– 机械盘建议 deadline，SSD/NVMe 建议 none 或 kyber；错配会导致响应时间陡增。 - 检查是否有强制同步写行为：
– 日志服务是否配置了sync=true；
– 数据库是否开启innodb_flush_log_at_trx_commit=1且事务极密集；
– 应用是否频繁调用fsync()或O_SYNC打开文件。
四、验证与临时缓解措施
在定位根因过程中，需快速止血，避免雪崩扩大。
- 对非核心高 IO 进程，可临时限速：
–ionice -c3 -p PID（设为 idle class）；
–cpulimit -p PID -l 10（间接压制 IO，因多数 IO 进程伴随少量 CPU）。 - 若确认是日志写满或轮转失败：
– 清理旧日志（find /var/log -name "*.log.*" -mtime +7 -delete）；
– 重启对应服务（如 rsyslog、filebeat）使其重新加载文件描述符。 - 检查磁盘健康：
– SATA/SAS 盘：smartctl -a /dev/sda | grep -E "(Reallocated|Pending|UDMA_CRC)"；
– NVMe 盘：nvme smart-log /dev/nvme0n1 | grep -E "(critical|temperature|media)"；
存在警告项需立即隔离设备。
