Linux磁盘I/O优化需围绕“请求来向、排队机制、落盘过程”系统梳理，核心是监控定位高I/O进程（iotop）与针对性调优（fio测试、调度器选择、挂载参数及缓存策略）。
Linux磁盘I/O优化不是堆砌工具或盲目调参，而是围绕“请求怎么来、怎么排、怎么落盘”这条主线做系统性梳理。核心抓手就两个：实时看清谁在吃I/O（监控），以及让数据更少、更快、更稳地进出磁盘（调优）。下面从实操角度拆解关键步骤。
用iotop精准定位高I/O进程
iotop是排查“谁在狂刷磁盘”的第一利器，它按进程维度显示实时读写速率和I/O等待占比。
- 运行 iotop -o -P -d1：只显示正在执行I/O的进程（-o），不展开线程（-P），每秒刷新一次（-d1）
- 重点关注 IO> 列（实际I/O带宽）和 IO% 列（该进程占用I/O总时间的百分比）；若某个进程IO%持续超30%，基本就是瓶颈源
- 结合 iotop -a 查看累计I/O量，识别长期缓慢但累积消耗高的“隐形大户”
- 注意区分 DISK READ 和 SWAPIN：后者说明进程因内存不足被换出，本质是内存问题引发的I/O放大
用fio模拟真实负载并量化瓶颈
fio不是跑个分就完事，关键是构造贴合业务特征的测试模型，验证优化是否真正生效。
- 数据库场景常用：fio --name=randread --ioengine=libaio --rw=randread --bs=4k --direct=1 --runtime=60 --time_based --group_reporting（随机读，绕过缓存，测真实磁盘延迟）
- 日志类写入场景：fio --name=seqwrite --ioengine=psync --rw=write --bs=128k --direct=0 --sync=1 --runtime=60（同步顺序写，考察文件系统+日志提交开销）
- 对比基线时，固定 --iodepth=32（队列深度）和 --numjobs=4（并发任务数），确保测试条件一致
- 重点看输出中的 iops、lat (avg)（平均延迟）、clat percentiles（如99%延迟），而非仅吞吐量
根据设备类型选对I/O调度器
调度器决定请求如何排队，选错等于给SSD套上机械盘的枷锁。
- SSD/NVMe盘：优先用 none（5.0+内核默认）或 kyber（NVMe专用，低延迟优化）；禁用cfq/deadline
- 传统HDD或虚拟机磁盘：用 deadline（防饿死，保障响应上限），避免cfq在单用户场景引入额外延迟
- 查看当前设置：cat /sys/block/sda/queue/scheduler（中括号标出当前生效项）
- 临时切换：echo kyber > /sys/block/nvme0n1/queue/scheduler；永久生效需在GRUB_CMDLINE_LINUX中加 elevator=kyber
挂载参数与缓存策略协同调优
文件系统行为直接影响I/O路径长度和数据落盘时机，几个关键参数必须按需启用。
- noatime：禁用访问时间更新，减少大量小文件读场景下的元数据写入，几乎无副作用
- barrier=1（ext4）或 data=ordered：保障崩溃后数据一致性，生产环境不应关闭
- vm.dirty_ratio=30 和 vm.dirty_background_ratio=10：控制页缓存刷盘节奏；数据库服务器可压至15/5，避免突发刷盘阻塞前台写入
- SSD务必配合 fstrim -v /mount/point 定时执行（如每周cron），或启用 discard 挂载选项（注意性能影响）
