磁盘I/O等待过高主要由存储延迟、ext4日志模式不当、文件系统碎片或inode耗尽、page cache回写策略不合理引起；需结合iostat、iotop、nvme smart-log等工具逐层排查。
磁盘 I/O 等待过高导致 write 系统调用阻塞
当 iowait 持续超过 20%，且 iotop -o 显示大量进程在 D（uninterruptible sleep）状态，基本可判定是底层存储响应延迟所致。常见于机械盘队列深度不足、SSD 长期写入后性能衰减、或 RAID 卡缓存电池失效后强制关闭 write-back 缓存。
实操建议：
- 用
iostat -x 1观察%util和await：若await > 50ms且%util ≈ 100%，说明设备已达吞吐瓶颈 - 检查 RAID 卡缓存策略：
MegaCli64 -AdpCachePolicy -Get -aALL，确认是否为WriteBack；若显示WriteThrough且 BBU 不健康，性能会断崖式下降 - 对 NVMe 盘，运行
sudo nvme smart-log /dev/nvme0n1查看media_errors和warning_temp_time
ext4 文件系统 journal 模式配置不当
默认 data=ordered 在大文件追加写或小文件高频创建时，journal 日志刷盘可能成为瓶颈；若误设为 data=journal，所有数据都先写 journal，再写 data block，I/O 放大近 2 倍。
实操建议：
- 查看当前挂载参数：
findmnt -t ext4 | grep -o 'data=[^,]*' - 生产环境高吞吐场景推荐
data=writeback（元数据仍 journal，数据不保证顺序），但需接受极端掉电下文件内容损坏风险 - 禁用 barrier（
barrier=0）可提升 SSD 性能，但仅限有 UPS 或断电保护的环境；否则ext4可能因乱序写入导致日志校验失败
文件系统碎片化或 inode 耗尽
ext4 在长期小文件写入后，即使磁盘空闲率 >30%，也可能因块组内 block 分散导致单次 write 需多次寻道；而 df -i 显示 inode 使用率 >95% 时，open() 和 mkdir() 会直接失败，间接拖慢上层写入流程（如日志轮转卡住）。
实操建议：
- 检查碎片程度：
e4defrag -c /mount/point（返回fragmentation factor>20% 需干预） - 扩容 inode 数量不可逆，建文件系统时应预估：
mke2fs -T largefile4 -N 200000000 /dev/sdb1 - 临时缓解 inode 耗尽：清理
/tmp下残留 socket、dead process 的/proc/PID/fd/符号链接（常被忽略）
page cache 回写策略触发脏页阻塞
当 vm.dirty_ratio 设为默认 20%，且业务突发写入大量数据，内核会在内存中积累脏页直到达阈值，随后阻塞所有新 write 直到回写完成——此时 top 看不到 CPU 占用高，但进程 WRITE 状态堆积。
实操建议：
- 监控脏页压力：
grep -i dirty /proc/vmstat关注nr_dirty和nr_writeback是否持续高位 - 调低
vm.dirty_background_ratio（如设为 5）让后台回写更积极，避免前台阻塞 - 对数据库等应用，可绑定
vm.dirty_ratio到 10–15，并配合vm.dirty_expire_centisecs=500加速过期脏页淘汰
真正难排查的是多层叠加：比如 RAID 卡缓存关闭 + ext4 data=journal + 脏页回写延迟，三者同时存在时，strace -e trace=write 看到的阻塞时间会远超单因素影响，必须逐层剥离验证。