RHEL 的 I/O 调度器(Scheduler)与 Database 的关系

今天参加 AIX 的技术培训，听了一些关于 CPU 调度的算法，倒也都是些基本知识，回想讲课内容的时候倒让我想起 Linux Kernel 的 I/O Scheduler 来。

这篇 Choosing an I/O Scheduler for Red Hat Enterprise Linux 4 and the 2.6 Kernel 是必须的参考资料。相比 Linux 2.4 Kernel 的一种 IO 调度器，2.6 做了很多改进，共有四种 IO 调度器。

Deadline scheduler

Deadline scheduler 用 deadline 算法保证对于既定的 IO 请求以最小的延迟时间，从这一点理解，对于 DSS 应用应该会是很适合的。

Anticipatory scheduler

Anticipatory scheduler（as) 曾经一度是 Linux 2.6 Kernel 的 IO scheduler 。Anticipatory 的中文含义是”预料的, 预想的”, 这个词的确揭示了这个算法的特点，简单的说，有个 IO 发生的时候，如果又有进程请求 IO 操作，则将产生一个默认的 6 毫秒猜测时间，猜测下一个 进程请求 IO 是要干什么的。这对于随即读取会造成比较大的延时，对数据库应用很糟糕，而对于 Web Server 等则会表现的不错。这个算法也可以简单理解为面向低速磁盘的，因为那个”猜测”实际上的目的是为了减少磁头移动时间。

Completely Fair Queuing

虽然这世界上没有完全公平的事情，但是并不妨碍开源爱好者们设计一个完全公平的 IO 调度算法。Completely Fair Queuing （cfq, 完全公平队列) 在 2.6.18 取代了 Anticipatory scheduler 成为 Linux Kernel 默认的 IO scheduler 。cfq 对每个进程维护一个 IO 队列，各个进程发来的 IO 请求会被 cfq 以轮循方式处理。也就是对每一个 IO 请求都是公平的。这使得 cfq 很适合离散读的应用(eg: OLTP DB)。我所知道的企业级 Linux 发行版中，SuSE Linux 好像是最先默认用 cfq 的.

NOOP

Noop 对于 IO 不那么操心，对所有的 IO请求都用 FIFO 队列形式处理，默认认为 IO 不会存在性能问题。这也使得 CPU 也不用那么操心。当然，对于复杂一点的应用类型，使用这个调度器，用户自己就会非常操心。

那么如果跑数据库应用，那个更好一些呢? 我们看Choosing an I/O Scheduler for Red Hat Enterprise Linux 4 and the 2.6 Kernel一文中的测试结果:

对于数据库应用, Anticipatory Scheduler 的表现是最差的。Deadline 在 DSS 环境表现比 cfq 更好一点，而 cfq 综合来看表现更好一些。这也难怪 RHEL 4 默认的 IO 调度器设置为 cfq. 而 RHEL 4 比 RHEL 3，整体 IO 改进还是不小的。

哪一种方式更好? 很难说，每一种方式都有特定的应用对它是最适合的。就像上面的 as 好像表现比较差，如果是 CPU 密集型的应用呢?

Tip:
Q:如何确认当前用什么 IO 调度器?
A: 过滤 /var/log/boot.msg 文件, 查找 “io scheduler”, 看到了么?

在 操作系统上可以查到的相关文档：
/usr/src/linux/Documentation/block/as-iosched.txt
/usr/src/linux/Documentation/block/deadline-iosched.txt

–EOF–

更新： Ubuntu Server 使用 Deadline 而不是桌面版的 CFQ 算法。

从很多实际测试场景来看，Deadline 更适合跑 MySQL 数据库。