磁盘io持续偏高本质是应用等待存储响应，需通过iotop、iostat定位io大户，结合await与%util判断瓶颈类型，再优化文件系统挂载参数、io调度器及应用刷盘策略。
磁盘IO持续偏高，本质是系统在等待存储响应，不是“磁盘忙”，而是“应用等得久”。关键要区分：是硬件吞吐不足、队列堆积、调度低效，还是上层逻辑频繁刷盘。直接看%util接近100%或await明显升高（比如>20ms），基本可确认存在IO瓶颈。
快速定位高IO源头
先别急着调参数，得知道谁在猛写猛读：
- 用 sudo iotop -o 查实时活跃进程，重点关注 DISK READ/WRITE 和 IO> 列，数值大的就是主力“IO大户”
- 配合 iostat -x 1 5 看设备级指标：r/s、w/s（IOPS）、rkB/s、wkB/s（吞吐）、await（平均等待时间）、%util（设备忙时占比）
- 如果 await 高但 %util 不高，说明请求在队列里排队，不是磁盘慢，可能是调度或并发控制问题；如果两者都高，更倾向硬件或负载本身过载
检查文件系统与挂载配置
很多IO压力其实是“自己加的”：
- 确认是否启用了 noatime 或 nodiratime：每次读文件更新访问时间会触发额外写入，加到 /etc/fstab 对应行末尾，如 defaults,noatime，然后 mount -o remount /
- 避免日志型文件系统在写密集场景下重复落盘，例如 ext4 可考虑 tune2fs -O ^has_journal /dev/sdX（仅限可信环境，禁用日志有风险）
- 数据库或日志目录尽量单独挂载，用 tmpfs 挂载 /tmp 或 /var/log/journal（内存盘），减少物理盘压力
调整IO调度器适配工作负载
Linux默认调度器不一定适合你的场景：
- SSD或NVMe盘推荐用 none（绕过调度，由设备自身管理）或 kyber（低延迟优化）
- 传统机械硬盘、虚拟机磁盘常用 deadline（兼顾延迟与吞吐）
- 查看当前设置：cat /sys/block/sdX/queue/scheduler；临时切换：echo kyber | sudo tee /sys/block/sdX/queue/scheduler
- 永久生效需在内核启动参数中加 elevator=kyber，或通过 udev 规则固化
从应用和内核层减少IO压力
系统调优之外，真正见效快的是“少做IO”：
- 数据库启用异步刷盘策略，例如 MySQL 设置 innodb_flush_log_at_trx_commit=2，牺牲一点持久性换性能
- 调小脏页刷新阈值，让内核更早批量刷出：vm.dirty_ratio=30、vm.dirty_background_ratio=10（写入型服务适用）
- 关闭不必要的服务日志，把 DEBUG 级日志降为 INFO，配合 logrotate 控制大小和轮转频率
- 对临时文件、缓存文件，优先使用内存映射（mmap）或直接写入 tmpfs，避免反复落盘
