有组数据值得注意：在我们托管的300多台服务器中，因为磁盘IO导致性能问题的占比接近35%，比CPU和内存问题加起来还多。而且IO问题更隐蔽——CPU高了top一眼能看到，IO高了很多人不知道怎么查。

服务器响应突然变慢，先别急着加硬盘。在硬件升级之前，有四个方向的调优往往能带来立竿见影的效果。

方向一：调整IO调度器

Linux内核默认的IO调度器不一定适合你的场景。机械硬盘上用CFQ调度器还行，但SSD和NVMe用CFQ就是浪费。SSD建议改成noop或者deadline，减少不必要的排序开销。查看当前调度器用cat /sys/block/sda/queue/scheduler，修改用echo deadline > /sys/block/sda/queue/scheduler。改完即时生效，不用重启。

有个客户的MySQL服务器，把调度器从CFQ改成deadline后，写吞吐量提升了23%。零成本，一条命令的事。

方向二：文件系统挂载参数优化

ext4和xfs是最常用的两个文件系统。无论用哪个，挂载参数都很关键。数据库服务器建议加上noatime参数，禁止更新文件访问时间戳，减少无意义的写操作。对于SSD，加上discard参数启用TRIM，或者改用持续TRIM fstrim.timer定期回收。

另外，文件系统的预留空间默认是5%，对于数据盘来说完全没必要。tune2fs -m 0 /dev/sda1把预留空间清零，能多出不少可用空间，对大容量盘效果明显。

方向三：用缓存挡住读请求

很多时候IO瓶颈其实是缓存没做好。热点数据应该放在Redis或者内存里，而不是每次都从磁盘读。对于数据库，innodb_buffer_pool_size建议设为可用内存的60%到70%。Linux层面的page cache也能挡住大量读请求，用free命令看buff/cache列，如果这个值很低说明缓存基本没利用上，要检查是不是被其他进程挤占了。

方向四：应用层减少无效IO

应用代码里的日志级别也是个隐形IO杀手。生产环境debug日志全开，一个请求打十行日志，高并发下光写日志就能把磁盘打满。把日志级别调到WARN或者INFO，异步写日志用buffer而非同步刷盘，IO压力立降。

四个方向排查下来，大部分IO瓶颈都能缓解。实在不行再考虑硬件升级，到时候加SSD或者上RAID阵列，收益会更大。