MySQL高阶讲座之：`MySQL`的`IO`调度器：`CFQ`、`deadline`和`noop`的选型。

各位观众老爷们，今天咱不开车，聊点硬核的——MySQL 的 IO 调度器！别一听“调度器”就打瞌睡，这玩意儿直接关系到你的数据库性能，选对了能让你的 MySQL 起飞，选错了… 咳咳，只能说“人生不如意事十之八九”了。

咱今天要讲的三个主角是：CFQ (Completely Fair Queuing)、deadline、以及 noop。 别怕，名字听着唬人，其实都是纸老虎，咱一个一个收拾。

1. 啥是 IO 调度器？为啥它重要？

先说个大白话：IO 调度器就像一个交通警察，专门负责指挥硬盘（或者 SSD）的读写请求。想象一下，你的 MySQL 同时要处理很多请求，比如查询、插入、更新等等，这些请求都要读写硬盘。如果没有警察指挥，这些请求就乱糟糟地一拥而上，硬盘忙得晕头转向，性能自然就差了。

IO 调度器的作用就是：

• 排序：把乱序的 IO 请求整理成有序的队列。
• 合并：把相邻的 IO 请求合并成一个更大的请求，减少硬盘寻道时间。
• 优先级：给不同的 IO 请求赋予不同的优先级，保证重要的请求先执行。
• 公平性：尽量保证每个进程都能公平地使用 IO 资源。

简单来说，IO 调度器就是为了让硬盘更有效率地工作，让你的 MySQL 跑得更快。

2. 三大主角登场：CFQ、deadline、noop

好了，铺垫了这么多，终于轮到我们的主角们登场了。

2.1 CFQ (Completely Fair Queuing)

CFQ 就像一个“绝对公平”的交通警察。它会为每个进程创建一个独立的 IO 队列，并且尽量保证每个进程都能公平地使用 IO 资源。

优点：

• 公平性好：适用于多用户、多应用的场景，可以避免某个进程占用所有 IO 资源的情况。
• 延迟可预测：由于公平性，可以相对容易地预测 IO 延迟。

缺点：

• 开销较大：需要维护多个队列，调度算法也比较复杂，会消耗一定的 CPU 资源。
• 不适合 SSD：对于 SSD 这种随机访问性能很高的设备，CFQ 的公平性调度反而会降低性能。

适用场景：

• 机械硬盘：在机械硬盘上，CFQ 可以有效地减少磁头寻道时间，提高整体性能。
• 多用户、多应用：适用于需要保证公平性的场景，比如共享数据库服务器。

配置 CFQ：

• 查看当前使用的调度器：

  cat /sys/block/sda/queue/scheduler  # 假设你的硬盘设备是 sda

  输出结果类似： noop deadline [cfq] mq-deadline kyber bfq (方括号表示当前正在使用的调度器)

• 临时切换调度器：

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

  注意： 这种方式重启后会失效。

• 永久切换调度器（以 CentOS 为例）：

  编辑 /etc/default/grub 文件，找到 GRUB_CMDLINE_LINUX 这一行，添加 elevator=cfq：

  GRUB_CMDLINE_LINUX="crashkernel=auto rhgb quiet elevator=cfq"

  然后执行以下命令更新 grub 配置：

  grub2-mkconfig -o /boot/grub2/grub.cfg

  重启系统后，新的调度器就会生效。

2.2 deadline

deadline 就像一个“有截止时间”的交通警察。它会为每个 IO 请求设置一个截止时间，优先处理那些快要超时的请求。

优点：

• 低延迟：可以有效地减少 IO 延迟，保证关键请求及时完成。
• 简单高效：调度算法比较简单，开销较小。

缺点：

• 公平性较差：可能会导致某些进程的 IO 请求被延迟。
• 可能饿死：长时间没有deadline的请求有可能被饿死。

适用场景：

• 机械硬盘：可以减少磁头寻道时间，提高整体性能。
• 延迟敏感型应用：适用于对 IO 延迟要求较高的应用，比如实时数据库。

配置 deadline：

与 CFQ 类似，可以使用以下命令查看和切换调度器：

• 查看当前使用的调度器：

  cat /sys/block/sda/queue/scheduler

• 临时切换调度器：

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

• 永久切换调度器（以 CentOS 为例）：

  编辑 /etc/default/grub 文件，找到 GRUB_CMDLINE_LINUX 这一行，添加 elevator=deadline：

  GRUB_CMDLINE_LINUX="crashkernel=auto rhgb quiet elevator=deadline"

  然后执行以下命令更新 grub 配置：

  grub2-mkconfig -o /boot/grub2/grub.cfg

  重启系统后，新的调度器就会生效。

2.3 noop

noop 就像一个“啥也不管”的交通警察。它不对 IO 请求进行任何排序或合并，只是简单地将请求放入一个 FIFO (First In, First Out) 队列中。

优点：

• 开销最小：调度算法非常简单，几乎不消耗 CPU 资源。
• 适用于 SSD：对于 SSD 这种随机访问性能很高的设备，noop 可以避免额外的调度开销。

缺点：

• 性能较差：对于机械硬盘，noop 无法减少磁头寻道时间，性能可能很差。
• 公平性差：完全按照请求的顺序执行，可能会导致某些进程的 IO 请求被延迟。

适用场景：

• SSD：在 SSD 上，noop 可以提供最佳的性能。
• 虚拟化环境：在虚拟化环境中，宿主机可以统一管理 IO 调度，虚拟机内部使用 noop 可以减少开销。

配置 noop：

与 CFQ 和 deadline 类似，可以使用以下命令查看和切换调度器：

• 查看当前使用的调度器：

  cat /sys/block/sda/queue/scheduler

• 临时切换调度器：

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

• 永久切换调度器（以 CentOS 为例）：

  编辑 /etc/default/grub 文件，找到 GRUB_CMDLINE_LINUX 这一行，添加 elevator=noop：

  GRUB_CMDLINE_LINUX="crashkernel=auto rhgb quiet elevator=noop"

  然后执行以下命令更新 grub 配置：

  grub2-mkconfig -o /boot/grub2/grub.cfg

  重启系统后，新的调度器就会生效。

3. 选型指南：到底该选哪个？

说了这么多，到底该选哪个 IO 调度器呢？ 别急，咱给你总结一下：

特性	CFQ	deadline	noop
公平性	很好	较差	很差
延迟	较可预测	低	不可预测
开销	较大	较小	最小
适用设备	机械硬盘，多用户环境	机械硬盘，延迟敏感型应用	SSD，虚拟化环境
推荐场景	共享数据库服务器，需要保证公平性的场景	实时数据库，需要低延迟的场景	MySQL 数据存储在 SSD 上，且不需要额外调度
是否需要调优	通常需要根据具体 workload 进行调优	也可以根据具体 workload 进行调优	通常不需要调优

简单来说：

• 如果你用的是机械硬盘，并且需要保证公平性，那就选 CFQ。
• 如果你用的是机械硬盘，并且对延迟要求很高，那就选 deadline。
• 如果你用的是 SSD，那就选 noop。

更详细的建议：

• MySQL 数据库服务器使用 SSD： 毫不犹豫地选择 noop。 现代 SSD 的内部控制器已经做了很好的 IO 调度，操作系统层面的调度反而会增加额外的开销。

• MySQL 数据库服务器使用机械硬盘，且是共享环境： CFQ 是一个不错的选择。 它能保证各个 MySQL 实例或应用之间公平地分享 IO 资源，避免某个实例独占 IO 导致其他实例性能下降。 当然，你需要根据实际的 workload 进行一些调优，例如调整 slice_idle 和 quantum 参数。

• MySQL 数据库服务器使用机械硬盘，且是专用环境，对响应时间要求高： deadline 可能更合适。 虽然公平性不如 CFQ，但它能尽可能地保证每个 IO 请求在截止时间前完成，从而降低整体的响应时间。 同样，也需要根据实际情况进行调优，例如调整 read_expire 和 write_expire 参数。

• 虚拟化环境： 在虚拟化环境中，通常建议在虚拟机内部使用 noop，而将 IO 调度的责任交给宿主机。 这样可以避免虚拟机内部和宿主机之间的调度冲突，提高整体性能。

一些调优选项 (针对 CFQ 和 deadline):

虽然 noop 一般不需要调优，但 CFQ 和 deadline 在某些情况下可以通过调整参数来获得更好的性能。 这些参数位于 /sys/block/sda/queue/iosched/ 目录下 (假设你的硬盘设备是 sda)。

CFQ 的一些常用调优参数：

• slice_idle: 每个进程在没有 IO 请求时可以空闲的时间，单位是微秒。 适当增加这个值可以减少进程切换的频率，提高吞吐量。
• quantum: 每个进程一次可以发送的 IO 请求数量。 适当增加这个值可以提高吞吐量，但可能会降低公平性。

deadline 的一些常用调优参数：

• read_expire: 读请求的截止时间，单位是微秒。
• write_expire: 写请求的截止时间，单位是微秒。 适当减少这些值可以降低延迟，但可能会降低吞吐量。

示例：

# 调整 CFQ 的 slice_idle 参数
echo 8 > /sys/block/sda/queue/iosched/slice_idle

# 调整 deadline 的 read_expire 参数
echo 500 > /sys/block/sda/queue/iosched/read_expire

重要提示： 调优 IO 调度器是一个复杂的过程，需要根据具体的 workload 和硬件配置进行调整。 在进行任何调优之前，一定要进行充分的测试，并确保你理解每个参数的含义。 盲目地修改参数可能会导致性能下降甚至系统不稳定。

4. 测试才是王道：实践出真知

说了这么多理论，最终还是要落实到实践。如何测试不同 IO 调度器的性能呢？

• 使用工具： 可以使用 iostat, iotop, blktrace 等工具来监控 IO 性能。
• 模拟 workload： 可以使用 fio 等工具来模拟不同的 workload，比如随机读写、顺序读写等等。
• 对比测试： 在相同的硬件和软件环境下，分别测试不同 IO 调度器的性能，并记录测试结果。

一个简单的 fio 测试示例：

fio --name=test --ioengine=libaio --direct=1 --sync=1 --bs=4k --numjobs=1 --size=1g --readwrite=randrw --rwmixread=70 --runtime=60 --group_reporting --time_based --filename=/data/testfile

这个命令会创建一个名为 test 的 fio 任务，模拟 70% 读 + 30% 写的随机读写 workload，持续 60 秒，并将结果以组的形式报告。

在测试之前，先切换到不同的 IO 调度器，然后运行 fio 测试，并记录测试结果。 比较不同调度器的测试结果，就可以选择最适合你的 workload 的 IO 调度器。

5. 总结：没有银弹，只有最适合的

最后，总结一下：

• 没有完美的 IO 调度器，只有最适合你的。
• 选择 IO 调度器要根据你的硬件、workload 和性能需求来综合考虑。
• 测试是选择 IO 调度器的关键。

希望今天的讲座对你有所帮助！ 记住，实践出真知，多多测试，才能找到最适合你的 MySQL IO 调度器。 祝你的 MySQL 跑得飞快！