数据库与deadline磁盘调度算法

概述

在数据库运维场景中，磁盘 I/O 性能直接影响系统整体响应速度，而磁盘调度算法作为操作系统管理磁盘 I/O 请求的核心机制，对数据库性能有着显著影响。本文围绕 Linux 下的磁盘调度算法展开，详细解释常见调度器的设计原理、适用场景和优缺点，重点分析在达梦数据库配置中推荐使用deadline算法的原因，并提供麒麟操作系统下的实操配置方案与性能对比测试结果，为数据库运维人员提供决策参考。

背景

在部署达梦数据库前，通常需要服务器将磁盘的调度算法设置为 deadline，特别是 arm 平台，必须要设置为 deadline。那么什么是磁盘调度算法？我们可以参考达梦官方文档中对安装前准备工作的相关描述：

每当进程需要进行磁盘 I/O 操作时，它就向操作系统发出一个系统调用。如果所需的磁盘驱动器和控制器空闲，则立即处理请求。如果磁盘驱动器或控制器忙，则任何新的服务请求都会添加磁盘驱动器的待处理请求队列。对于具有多个进程的一个多道程序系统，磁盘队列可能有多个待处理的请求。因此操作系统如何选择待处理请求的服务便是磁盘调度算法。

摘自：安装前准备工作 | 达梦技术文档

麒麟操作系统中修改磁盘调度算法

对于麒麟操作系统，我们可以通过下列操作修改磁盘调度算法：

使用nkvers检查系统版本

nkvers

#输出
############## Kylin Linux Version #################
Release:
Kylin Linux Advanced Server release V10 (Halberd)

Kernel:
4.19.90-89.11.v2401.ky10.x86_64

Build:
Kylin Linux Advanced Server
release V10 SP3 2403/(Halberd)-x86_64-Build20.01/20240426
#################################################

找到数据盘对应的物理盘

lsblk

#输出
NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda             8:0    0   20G  0 disk 
├─sda1          8:1    0    1G  0 part /boot
└─sda2          8:2    0   19G  0 part 
  ├─klas-root 253:0    0   17G  0 lvm  /
  └─klas-swap 253:1    0    2G  0 lvm  [SWAP]
sr0            11:0    1  4.4G  0 rom  /run/media/root/Kylin-Server-10
#此处是虚拟机环境，仅配置了一个磁盘，故数据盘为sda

查看当前系统支持的算法

dmesg | grep -i scheduler

#输出
[    1.785368] io scheduler mq-deadline registered
[    1.785369] io scheduler kyber registered
[    1.785429] io scheduler bfq registered

查看系统当前磁盘调度算法

cat /sys/block/sda/queue/scheduler

#输出
[mq-deadline] kyber bfq none    #当前默认启用的为deadline算法

临时修改磁盘调度算法，重启后失效

echo deadline > /sys/block/sda/queue/scheduler    #将磁盘调度算法改为deadline

为什么需要使用deadline算法？

在回答这个问题前，我们先了解一下常见的几种磁盘调度算法。

CFQ (完全公平排队 I/O 调度程序)

CFQ 全称 Completely Fair Queuing，中文名称完全公平排队调度器。它会将各个进程提交的同步请求分别放到不同的队列中，然后为每个队列分配时间片来访问磁盘，从而实现进程间 I/O 带宽的公平性。
CFQ 的优点是对桌面环境或多进程并发负载友好，能确保进程间的公平性；缺点是对于数据库类的长事务、大量随机 I/O 场景，性能可能不佳。在现代多队列环境下，CFQ 已经逐渐被替代。
适用场景：桌面系统、需要公平分配 I/O 资源的混合工作负载。

BFQ (预算公平队列调度程序)

BFQ 全称 Budget Fair Queuing，中文名称预算公平队列调度器。它是 CFQ 的改进版，通过为进程分配“预算”(quota) 的方式来调度 I/O，以改善交互延迟和系统响应速度。
BFQ 在交互延迟和吞吐量之间做了折中，能带来较好的桌面体验。但由于实现复杂，对于数据库类的高负载环境，优势并不明显。
适用场景：需要更好交互体验的桌面环境或混合型服务器。

Deadline (截止时间调度程序)

Deadline 中文名称截止时间调度器。它为读写请求分别维护两个按扇区号排序的队列，同时设置读写请求的截止时间（deadline）。当有请求达到超时时间时，调度器会强制优先处理，以避免请求长期饥饿。
Deadline 的默认策略是读请求优先于写请求，从而保证读取延迟较低。这种机制能有效降低数据库类随机 I/O 的响应时间。缺点是对于纯顺序写入场景，吞吐量可能不如 NOOP。
适用场景：数据库服务器、需要稳定 I/O 延迟保证的后端应用。

NOOP (电梯式调度程序)

NOOP 全称 No Operation，中文名称电梯式调度器。它实现了最简单的 FIFO 队列，基本不进行复杂的调度操作，只是简单地合并相邻的 I/O 请求后按照先来先服务提交给设备。
NOOP 的开销最小，适合那些自身具备高效 I/O 调度能力的固态存储设备。但在机械硬盘上，缺少重排序和合并优化会导致随机访问性能很差。
适用场景：固态存储设备。

Kyber (低延迟多队列调度程序)

Kyber 是 Linux 为多队列块设备（blk-mq）设计的调度器。它通过为不同类型的请求设置服务目标，控制队列深度，以实现低延迟和较高吞吐之间的平衡。
Kyber 的优点是设计简单，延迟可控，在虚拟化和延迟敏感的场景下表现优秀。但在极端高并发的顺序 I/O 场景下，吞吐量可能不如 mq-deadline。
适用场景：虚拟化宿主机、对延迟敏感的现代多队列存储设备。

提示 💡

对于现代 SSD/NVMe，设备本身的并发与内部调度能力强，内核过度排序反而可能降低性能，因此此类设备 IO 调度算法只有 none，则无需设置。

对比测试

通过设计一个对比测试，我们可以直观的感受的各个调度算法的性能差别。此处我们仅做一个测试设计，不涉及实际执行。

测试场景

• 读场景：高并发查询（单表查询、关联查询）
• 写场景：批量插入、事务提交
• 混合场景：70% 读 + 30% 写（模拟真实业务）

测试数据准备（员工信息表 + 百万级数据）

CREATE TABLE employee (
    id      BIGINT PRIMARY KEY,
    name    VARCHAR(100),
    dept_id INT,
    salary  DECIMAL(10,2),
    join_date DATE,
    remarks VARCHAR(255)
);
/* 为查询加索引 */
CREATE INDEX idx_employee_dept ON employee(dept_id);

使用sqlark的数据生成功能，为数据库添加百万级的数据

SQL 事务示例

我们可以使用jmeter等压测工具，在选定磁盘调度算法后，对数据库进行读写混合的压力测试，记录吞吐量。

• 读（主键查找）：

SELECT id, name, salary FROM employee WHERE id = ?;

读（范围）：

SELECT id, name FROM employee WHERE dept_id = ? ORDER BY join_date DESC LIMIT 100;

写（单条插入，或批量）：

INSERT INTO employee (id, name, dept_id, salary, join_date, remarks) VALUES (?, ?, ?, ?, ?, ?);

注意 ⚠

写压力请控制事务提交频率（例如每 100 条 commit），避免单次过大事务导致长时间锁或日志膨胀。

执行方法

• 切换调度算法（如deadline则）：

  echo deadline > /sys/block/sda/queue/scheduler

• 启动 JMeter 压测脚本

• 记录结果（响应时间、TPS、CPU 消耗、IOPS）

• 更换调度算法重复测试

小结

最后我们可以通过列一个对比表格并做出结论

调度算法	优点	缺点	举例类比	适用场景
CFQ (完全公平排队)	公平分配 I/O，避免进程饿死	数据库高并发下性能差	食堂轮流打饭	桌面系统、多进程公平调度
BFQ (预算公平队列)	改进公平性，响应快	实现复杂，数据库场景优势不明显	食堂打饭，饿的人吃多点	桌面、混合服务器
Deadline (截止时间)	保证读请求低延迟，适合数据库	顺序写吞吐不如 NOOP	快递急件插队	数据库服务器、OLTP
NOOP (电梯式)	开销小，适合 SSD/NVMe	HDD 随机 I/O 性能差	电梯先来先走	SSD、硬件 RAID
Kyber (低延迟 MQ)	多队列优化，延迟可控	吞吐量略差	银行多柜台限流排队	虚拟化宿主机、延迟敏感场景

在数据库的典型 OLTP 场景中，deadline 调度算法表现最优，它保证了查询类请求的延迟稳定性，非常适合 高并发读写混合场景。