必须执行cat /sys/block/设备名/queue/scheduler确认方括号内值已变更，如输出为[mq-deadline] kyber none则生效；若NVMe设备显示[none]属正常，不可强行修改；iostat -x需重点观察await和avgqu-sz是否改善，而非%util。
怎么确认 IO 调度器改没生效
改完 elevator=deadline 或写入 /sys/block/sda/queue/scheduler 后，别信“应该好了”，得亲眼看到方括号里变过来才算数。常见错误是设备名写错（比如把 nvme0n1 写成 nvme0），或者改的是逻辑卷（dm-0）而非物理设备（sda）。
- 执行
cat /sys/block/sda/queue/scheduler（把sda换成你实际的设备名） - 输出必须是类似
[mq-deadline] kyber none这样——方括号里的才是当前激活项 - 如果只看到
[none]，且设备是 NVMe，基本不用再试；强行写noop会失败或被忽略 - 云服务器（如阿里云 EBS、AWS gp3）常返回
[none]且不可写，这不是配置问题，是平台限制
iostat -x 1 看什么指标才说明调度器起效
别盯着 %util ——它接近 100% 可能只是调度器在控速，不是真瓶颈。真正反映调度效果的是请求排队和延迟行为，重点盯两个字段：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
-
await：平均每次 I/O 的等待时间（毫秒）。HDD > 10ms、SSD > 1ms 才算异常；改完后这个值明显下降，说明调度减少了排队等待 -
avgqu-sz：平均队列长度。长期 > 1 且伴随高await，说明请求在内核队列里堆着；降到 0.2–0.5 以下，才是调度器“疏通”了 -
r_await/w_await分开看更准：如果读延迟高但写正常，可能跟调度器无关，是文件系统或 RAID 层问题 -
svctm已被内核弃用，输出恒为 0 或无效，直接忽略
为什么压测前后 iostat 数值没变化
调度器调优不是万能加速器，它只在特定瓶颈下起作用。如果压测工具（如 fio）本身发的是大块顺序 IO，或者设备已到硬件极限，换 mq-deadline 和 kyber 差异微乎其微。
- 典型有效场景：小 IO 随机读写密集（如数据库事务、日志刷盘），此时调度器合并与排序才有意义
- 无效场景：单线程大块顺序写（
fio --rw=write --bs=1M），IO 路径几乎不经过调度层 - 验证时要用贴近业务的负载：比如对 MySQL 实例跑 sysbench oltp_read_write，而不是空盘跑 dd
- 注意设备识别一致性：重启后
sda可能变sdb，临时修改失效；永久配置又统一作用于所有块设备，无法按盘区分
调度器参数微调后怎么验证是否适配业务
像 write_expire、fifo_batch 这类参数，改了未必更好，必须结合具体负载观察。它们只影响调度器内部行为，不改变底层吞吐能力。
- 改前先记 baseline：
iostat -x 1 30 > before.log - 改参数后同样压测，对比
await和avgqu-sz波动范围，而非单点峰值 - 例如调大
write_expire对日志型顺序写有利，但会让随机写响应变慢；要平衡延迟与吞吐 - 所有
/sys/block/*/queue/iosched/下的参数都是运行时生效，重启丢失；需写进 udev 规则或启动脚本才能持久
iotop -o 确认是不是真有进程在高频刷盘，再决定要不要动调度器。 
