直接查看/sys/block/设备名/queue/scheduler输出中方括号内项即当前生效调度器，如[mq-deadline] kyber bfq none中mq-deadline为当前值；不同内核版本默认值不同，5.0+多用mq-deadline，桌面环境可能启用bfq，lsblk和ionice无法反映调度器状态。
怎么确认当前磁盘IO调度器是什么
直接看 /sys/block/<device>/queue/scheduler</device> 是最准的，比如你的根盘是 sda，就执行：
cat /sys/block/sda/queue/scheduler
输出类似 [mq-deadline] kyber bfq none，方括号里那个就是当前生效的调度器。注意：不同内核版本默认值不同（5.0+ 多数用 mq-deadline，带桌面环境可能启用了 bfq），别只看安装文档默认值。
常见误区：lsblk -D 不显示调度器；ionice 控制的是进程 IO 优先级，和底层调度器无关。
哪些指标能反映调度器优化效果
调度器本身不提速单次读写，它影响的是请求合并、排序、延迟分布和多队列吞吐稳定性。重点盯这三项：
-
iostat -x 1中的await（平均每次 I/O 等待毫秒数）——bfq在混合负载下常压低此值，none（即绕过调度）在 NVMe 上可能更低 -
avgqu-sz（平均队列深度）——kyber和mq-deadline对队列长度更敏感，值突增往往说明调度策略没跟上负载节奏 -
r_await与w_await差值大幅拉大（比如读 2ms、写 40ms）——可能是bfq的权重机制在起作用，也可能是调度器被大量随机小 IO 淹没
别只看 %util：NVMe 盘跑满时它常卡在 100%，但实际延迟可能很低，这个值对调度器评估意义有限。
怎么对比不同调度器的真实效果
切调度器必须配合可复现的 IO 负载，否则对比无效。推荐用 fio 做三组基线测试：
宝塔Linux面板11.8.1
下载
宝塔Linux面板11.8.1为官网当前正式版，新增AI建站能力并经过宝塔网站工程师深度调教，开放自定义AI功能API，同时对WAF进行界面重构和深度优化，提升拦截能力与运维效率。
echo 'bfq' | sudo tee /sys/block/sda/queue/scheduler
然后立即运行：
fio --name=randread --ioengine=libaio --rw=randread --bs=4k --direct=1 --runtime=60 --time_based --group_reporting
重复三次，换 mq-deadline 和 none 再测。关键比对点：
- 同一 workload 下，
lat (usec)的99.9th百分位延迟（不是平均值） -
IOPS波动标准差（bfq通常更稳，none可能峰值高但抖动大） - 是否触发了
dmesg | grep -i "scheduler"中的警告（比如bfq: warning: too many groups）
注意：改调度器后要等至少 10 秒再测，内核需要时间完成队列重建；SSD 和 HDD 对 bfq 响应差异极大，别拿 SATA SSD 的结论套 NVMe。
哪些场景下调度器切换反而有害
不是所有磁盘都适合调。以下情况建议锁死默认或用 none：
- NVMe 设备启用多路径（如
nvme-cli显示多个nvme0n1子路径）——bfq会干扰硬件内部队列管理 - 数据库 WAL 日志盘跑
sync=always+ 小块写 ——mq-deadline的 deadline 机制比bfq更适合保延迟下限 - 容器环境挂载
overlay2到机械盘 ——bfq默认 group 配额太激进，容易饿死某个容器的 IO
真正影响 IO 效果的，往往是文件系统挂载选项（如 noatime,commit=60）和块设备对齐，调度器只是最后一层微调。改之前先确认你的瓶颈真在调度层，而不是 vm.swappiness 过高或日志刷盘太勤。
