服务器 IO 性能优化的关键，不是单纯升级硬件，而是按层级进行精准适配。RAID 需要结合业务场景合理选型，例如 OLTP 场景通常优先考虑 RAID10；IO 调度器要匹配存储介质特性，NVMe 更适合 kyber，HDD 更适合 deadline；缓存配置则应分三层实施——包括 Page Cache 参数调优、RAID 卡启用 Write-Back 并配合 BBU，以及文件系统挂载参数优化。最后，还要借助 iostat、iotop、smartctl 等工具做诊断分析，才能准确定位真正的 IO 性能瓶颈。
服务器 IO 性能优化并不是简单“堆配置”，而是讲究分层匹配：从磁盘阵列方案、Linux 内核 IO 调度策略，到缓存机制和文件系统参数设置，每一层都要贴合实际业务负载。核心思路不在于把所有优化项全部开启，而在于根据场景做精准配置。
RAID 级别按业务选择，不要只盯着速度
RAID 并非级别越高越好，真正决定方案的是读写模式、容量需求以及容错要求：
- OLTP 数据库、虚拟化平台：优先选择 RAID 10 —— 读写性能均衡、容错能力强（同组允许一块磁盘故障），通常 4 块盘起步，性能接近 RAID 0，同时保留镜像冗余，适合对延迟和稳定性要求高的业务。
- 日志或临时数据池：可以使用 RAID 0 —— 吞吐能力最高，但没有任何容错能力，只适用于数据可丢失、追求极致性能的场景。
- 归档/备份存储：RAID 6 更加稳妥 —— 支持两块磁盘同时损坏，容量利用率高于 RAID 10，虽然写入性能弱一些，但在以读取为主的归档和备份场景中影响较小。
- 中小业务主存储：RAID 5 属于折中方案 —— 成本较低、读取性能不错，但写入过程需要做校验计算，高并发写入时延迟会更明显，建议配合写缓存和 BBU 一起使用。
IO 调度器要跟着介质类型走，别直接沿用默认值
Linux 默认的 cfq 调度策略在 SSD 或 NVMe 场景下往往会拖累性能，因此需要按磁盘类型进行调整：
- NVMe SSD：建议使用 none 或 kyber —— NVMe 本身具备深度队列管理能力，内核层调度越轻量越好；其中 kyber 更适合混合读写负载。
- SATA/SAS SSD：推荐 deadline 或 mq-deadline —— 可以避免请求长期等待，同时兼顾整体响应延迟。
- 机械硬盘（HDD）：依然可以使用 mq-deadline，避免 cfq 在高并发场景下引入额外排队延迟。
- 查看当前调度器设置：
cat /sys/block/sdX/queue/scheduler；临时切换方式：echo kyber > /sys/block/sdX/queue/scheduler；如果希望永久生效，需要将elevator=kyber添加到 GRUB 内核启动参数中。
缓存配置要分三层分别优化
缓存并不是越大越有效，重点在于让操作系统、RAID 控制器和文件系统各自发挥合适的作用：
- OS Page Cache：可适当调低
vm.dirty_ratio（例如设为 10）和vm.dirty_background_ratio（例如设为 5），避免脏页积压过多后集中刷盘，引发明显卡顿；对于数据库类应用，如果已经启用了自身缓冲池（如 InnoDB Buffer Pool），可以考虑启用O_DIRECT绕过 Page Cache，减少双重缓存带来的开销。 - RAID 卡缓存：建议务必开启 Write-Back 模式，并搭配 BBU（电池或电容备份）使用，否则一旦断电可能造成数据丢失；Read-Ahead 可以开启，但主要对顺序读取有效，如果业务以随机读为主，则更建议关闭。
- 文件系统挂载选项：SSD 可使用
noatime,nodiratime,discard,barrier=0；HDD 可使用noatime,nodiratime,data=ordered；在文件系统选择上，XFS 更适合大文件和高并发场景，EXT4 兼顾稳定性，Btrfs 一般较少用于生产核心存储环境。
不要忽视基础诊断这一步
在正式做服务器 IO 性能调优之前，先确认系统是否真的存在 IO 瓶颈：
- 执行
iostat -x 1，观察%util是否长期超过 90%，以及await是否持续高于 10ms（SSD）或 20ms（HDD）； - 通过
iotop找出真正消耗 IO 的进程，避免误判问题来源； - 使用
smartctl -a /dev/sdX检查磁盘健康状态，排除坏道、重映射计数上升等硬件风险； - 同时确认应用层本身是否存在小文件高频随机写、未正确处理 fsync、锁表竞争严重等问题——很多看似“磁盘 IO 高”的现象，本质上其实是程序实现或 SQL 设计不合理造成的。
