Linux服务器磁盘IO瓶颈优化
你的服务器是不是“卡”在了磁盘IO上？
当你发现网站响应变慢、top命令里wa（等待磁盘IO的CPU时间）超过30%，或者iowait居高不下，这多半是磁盘IO瓶颈在作祟。
本文手把手教你用几条常用命令找到瓶颈，并给出5个立即可执行的优化操作——全程不需要很深的技术背景。
需要准备什么
- 一台Linux服务器（本文以CentOS 7/8和Ubuntu 20.04为例）
root权限或能执行sudo的普通用户- 安装好
sysstat和iotop工具（后面会给出安装命令）
第一步：用 iostat 和 top 确认瓶颈
先登录服务器，跑一条命令看看整体情况：
# CentOS / RHEL
sudo yum install -y sysstat dstat
# Ubuntu / Debian
sudo apt install -y sysstat dstat然后执行：
iostat -x 1 5重点关注这几列：
- r/s、w/s：每秒读写请求数（IOPS）
- rKB/s、wKB/s：每秒读写数据量
- await：平均每次IO请求的处理时间（毫秒）。如果超过20ms可能就有问题
- %util：磁盘忙碌百分比。100%表示磁盘已满负荷
同时另开一个终端跑top，观察wa值。
如果wa持续超过30%且%util接近100%，基本可以判定磁盘是瓶颈。
第二步：调整I/O调度器（立竿见影）
不同设备有不同调度器，用cat /sys/block/sda/queue/scheduler查看当前调度器。
SSD建议用noop或none，机械盘用deadline。
临时切换：
echo deadline > /sys/block/sda/queue/scheduler永久生效需修改/etc/default/grub（不同发行版有差异），这里不展开。
如果只是临时压测可以先用。
第三步：优化挂载参数
修改/etc/fstab对应分区的挂载选项，加上noatime（关闭文件访问时间更新）能减少大量小写IO。
示例：
/dev/sda1 / xfs defaults,noatime 0 0改完后执行mount -o remount /使生效。
第四步：调整内核参数减少脏数据回写压力
查看当前值：
sysctl vm.dirty_background_ratio
sysctl vm.dirty_ratio如果服务器内存较大（>=16GB），可适当降低：
sudo sysctl -w vm.dirty_background_ratio=5
sudo sysctl -w vm.dirty_ratio=10写入/etc/sysctl.conf永久生效。
注意不要设太激进，避免内存紧张。
第五步：应用程序层面排查
很多中间件有自己的IO相关参数。
比如MySQL的innodb_io_capacity和innodb_flush_method，适当调高可以提升刷盘效率。
WordPress等应用则检查是否开启了过多的日志写入。
避坑提醒
- %util 100%不等于故障：如果
await正常（<10ms），可能只是磁盘一直有请求，没有真正排队，实际性能还可以。 - 不要盲目调大 dirty_ratio：设置过高会导致大量脏数据积压，一次回写造成瞬时IO风暴。
- iostat 看到的指标需要结合应用场景：例如数据库要求低延迟，高IOPS场景下
await比%util更重要。
如何验证优化效果
优化后再跑一遍iostat -x 1 5和top，主要对比：
await是否下降%util是否仍接近100%wa是否降低到30%以下
如果数据明显好转，且应用响应时间缩短，说明优化生效。
高频问题解答
Q：我该用哪个IO调度器？
A：SSD + 多队列NVMe 推荐none（即 noop）；传统SATA SSD 选deadline；机械盘选deadline。
Q：iostat 显示 await 很高，但 %util 很低，怎么回事？
A：可能是磁盘本身响应慢（如U盘），或者是文件系统/内核IO栈的排队延迟，建议用blktrace进一步定位。
Q：调整完参数后需要重启吗？
A：大部分参数通过sysctl即时生效；挂载参数需remount或重启；调度器写/sys即时生效。
总结
Linux服务器磁盘IO瓶颈优化不是玄学，只要抓住定位→调整→验证三个环节，大多数场景都能缓解。
本文提供的 iostat 定位法、调度器切换、noatime、内核参数这几个操作，成本低、见效快，适合运维新手直接复制执行。
如果问题依然严重，再考虑硬件升级或调整业务架构。
相关阅读：如果你经常遇到 IO 高负载，还可以结合dstat和perf深入分析；
想了解文件系统选择对IO的影响，可以参考 Linux 下 xfs 与 ext4 的区别教程。
