最直接查当前调度算法的方式是读取/sys/block/设备名/queue/scheduler，如cat /sys/block/sda/queue/scheduler显示[noop] deadline cfq；NVMe设备返回none属正常，因其由硬件自行调度。
怎么查当前用的是哪个调度算法
最直接的方式是读取 /sys/block/设备名/queue/scheduler，它会显示当前激活的调度器，以及所有可用选项（括号里标出的是当前选中项）：
cat /sys/block/sda/queue/scheduler [noop] deadline cfq
注意：sda 要替换成你实际的磁盘设备名（可用 lsblk 查看）。如果看到多个设备，比如 sda 是 SSD、sdb 是 HDD，它们可以且应该配置不同调度器。
常见错误现象：执行 cat /sys/block/nvme0n1/queue/scheduler 却返回 none 或空——这是正常的，NVMe 设备默认不启用内核 I/O 调度器（由硬件控制器自行调度），强行写入会报错 Invalid argument。
Deadline 为什么适合数据库，但别乱设超时值
Deadline 的核心不是“快”，而是“不饿死”：它为每个读请求设 500ms 截止时间、写请求设 5s 截止时间，确保事务不会卡在队列尾部无限等待。这对 MySQL 的 innodb_flush_log_at_trx_commit=1 场景尤其关键。
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- 读超时太短（如设成 100ms）：频繁触发截止时间强制调度，反而打乱顺序合并，吞吐量下降
- 写超时太长（如设成 30s）：可能掩盖底层磁盘响应异常，让监控误判为“正常排队”
- 机械盘上启用 Deadline 后
iostat -x显示await波动变大？这是正常行为——Deadline 主动放弃长等待请求去服务新请求，await均值失真，应重点关注%util和r/s/w/s
Noop 在 SSD 上真省 CPU，但 RAID 卡要小心
Noop 就是纯 FIFO 队列，不做排序、不计算截止时间，CPU 占用几乎为零。对 NVMe 或 SATA SSD 效果明确，但遇到某些老款 RAID 卡（如 LSI MegaRAID 9260）时可能适得其反：
- RAID 卡固件本身有调度逻辑，若内核再用
Noop，等于放弃请求合并机会，小 IO 碎片加剧 - 实测发现：某 Dell R720 搭载 PERC H710P + 4×SSD RAID10，用
Noop后随机写 IOPS 下降 18%，改用deadline反而更稳 - 判断依据：运行
iostat -x 1，若avgrq-sz长期低于 8（即平均请求小于 4KB），说明上层没做有效合并，此时Noop不一定是最佳选择
CFQ 的“公平”在容器环境里容易失效
CFQ 按进程分队列、按时间片轮转，听起来很理想。但在 Docker/Kubernetes 场景下，问题来了：
- 同一个宿主机上跑 20 个 nginx 容器，它们的进程 UID 相同（默认都用 root 或 101），CFQ 会把它们视作“一个进程”，结果一个容器突发流量就能吃掉全部 I/O 带宽
- 使用 cgroups v1 时，可通过
blkio.weight限制，但 v2 默认关闭 blkio controller，需手动启用：systemctl set-property --runtime -- system.slice "IOWeight=100" - 更现实的做法：在容器密集型服务器上，直接切到
deadline，用应用层限流（如 Nginx 的limit_req）替代内核级公平性
真正影响调度效果的，从来不是算法名字，而是你的硬件拓扑、I/O 模式、以及是否混淆了“调度器该管什么”和“该由谁来管”。比如日志刷盘慢，先看 vm.dirty_ratio 是否堵住 writeback，而不是急着换调度器。
