1. Linux 内核 Block IO 调度器深度解析

当你在Linux系统上同时运行数据库服务和视频转码任务时，是否遇到过磁盘I/O性能骤降的情况？这背后其实是Block IO调度器在默默决定着每个I/O请求的处理顺序。作为连接文件系统和物理磁盘的中间层，调度器的算法选择直接影响着系统的吞吐量和响应延迟。

我曾在生产环境中遇到过MySQL查询突然变慢的问题，最终发现是默认的CFQ调度器在高并发随机写入场景下的瓶颈所致。本文将基于Linux 5.15内核代码，拆解四种主流调度器的工作原理、适用场景和调优方法，包含大量从内核开发者邮件列表中获取的一手优化建议。

2. Block IO 调度器核心机制

2.1 调度器在内核栈中的位置

位于Linux存储栈的倒数第二层（如图1），上层是文件系统层，下层是设备驱动层。其主要职责包括：

• 合并相邻的I/O请求（减少磁头移动）
• 排序请求（优化寻道时间）
• 限流控制（避免单个进程饿死）

// 内核中的调度器注册接口（block/blk-core.c） void blk_register_queue(struct gendisk *disk) { elevator_init(disk->queue); // 初始化调度器 }

2.2 四种调度器对比

实测提示：在NVMe SSD上，NOOP相比CFQ可提升约15%的4K随机读写IOPS

3. 调度器实现细节剖析

3.1 Deadline调度器防饿死机制

通过两个独立队列实现：

• 排序队列（按LBA地址排序）
• FIFO队列（按到达时间排序）

// 关键数据结构（block/deadline-iosched.c） struct deadline_data { struct rb_root sort_list[2]; // 读写排序树 struct list_head fifo_list[2]; // 超时队列 int fifo_expire[2]; // 超时时间(ms) };

当请求在FIFO队列中停留超过500ms（可调参）时，会被强制调度。这个机制特别适合MySQL这类需要稳定延迟的OLTP场景。

3.2 BFQ的权重分配算法

采用类似CFS的公平队列策略，但针对块设备特点优化：

1. 每个进程分配时间片（基于权重）
2. 突发流量处理（budget机制）
3. 低延迟模式（strict_guarantees参数）

# 调整BFQ权重示例（cgroup v2） echo "io.bfq.weight=300" > /sys/fs/cgroup/testgroup/io.bfq.weight

4. 生产环境调优指南

4.1 调度器选择决策树

graph TD A[存储类型?] -->|SSD/NVMe| B(NOOP或None) A -->|HDD| C{负载类型?} C -->|多进程混合| D[BFQ] C -->|数据库| E[Deadline] C -->|桌面应用| F[CFQ]

4.2 关键参数调整

• deadline:

  echo 100 > /sys/block/sda/queue/iosched/read_expire # 读超时(ms) echo 5 > /sys/block/sda/queue/iosched/fifo_batch # 批量提交数

• bfq:

  echo 1 > /sys/block/sda/queue/iosched/low_latency # 启用低延迟模式 echo 50 > /sys/block/sda/queue/iosched/timeout_sync # 同步超时(ms)

4.3 性能测试对比

使用fio测试4K随机读(iodepth=32)：

5. 疑难问题排查实录

5.1 案例：NVMe磁盘性能波动

现象：使用BFQ时出现周期性IOPS下降
排查：

1. 检查调度器参数：

   cat /sys/block/nvme0n1/queue/scheduler

2. 发现low_latency=1导致吞吐下降
   解决：

   echo 0 > /sys/block/nvme0n1/queue/iosched/low_latency

5.2 案例：cgroup权重不生效

现象：设置io.bfq.weight后无效果
原因：内核编译时未开启CONFIG_BFQ_CGROUP_DEBUG
验证：

grep BFQ_GROUP_IOSCHED /boot/config-$(uname -r)

6. 进阶开发指南

6.1 自定义调度器开发

1. 实现elevator_type接口：

   static struct elevator_type my_iosched = { .ops = { .elevator_merge_fn = my_merge, .elevator_dispatch_fn = my_dispatch, }, .elevator_name = "my_scheduler", .elevator_owner = THIS_MODULE, };

2. 注册到block层：

   module_init(my_scheduler_init);

6.2 使用BPF跟踪调度决策

// 跟踪dispatch事件的BPF程序 SEC("tracepoint/block/block_rq_issue") int bpf_block_issue(struct args *ctx) { bpf_printk("Dispatched %llu bytes", ctx->nr_bytes); return 0; }

在NVMe存储普及的今天，调度器的选择需要重新审视。最新的Linux 6.0内核中，BFQ已支持多硬件队列（blk-mq）架构，而传统的CFQ正逐步被移除。建议结合blktrace和perf工具进行深度 profiling，才能找到最适合你工作负载的I/O路径优化方案。