如何选择IO调度器

概述#

由于对multi-quque的IO调度算法不太熟悉，为了避免误人子弟，本文暂时只会介绍如何选择single-queue的IO调度算法。等将来对multi-queue有充分认识后再补充。

如果不清楚什么是single-queue和multi-queue，可以看这文章《块层介绍第二篇: request层》

最新版本的Linux内核已经完全切到multi-queue架构，因此single-queue下的IO调度算法在最新内核可能已经销声匿迹了。但实际上，multi-queue的IO调度算法很大程度上参考了single-queue的IO调度算法，因此一定程度上可以类推。

单队列调度算法	多队列调度算法
deadline	mq-deadline
cfq	bfq
noop	none
	kyber

为什么需要IO调度呢？在最开始的时候，Linux存储在磁盘上。磁盘盘片高速旋转，通过磁臂的移动读取数据。磁臂的移动是物理上的机械上的移动，它无法瞬移，这速度是很慢的。如果我们读取的数据位置很随机，一会在A地点，一会在隔着老远的B地点，移动的时间就全做了无用功，这也就是我们说的随机读写性能慢的原因。如果读取的数据地址是连续的，即使不是连续的也是地址接近的，那么移动磁臂的时间损耗就少了。在最开始，IO调度的作用就是为了合并相近的IO请求，减少磁臂的移动损耗。

单队列调度算法#

单队列架构下，常用的调度算法有3种：noop，deadline和cfq

noop#

noop只会对请求做一些简单的排序，其本质就是一个FIFO的队列，只会简单地合并临近的IO请求后，本质还是按先来先处理的原则提交给磁盘。

根据它的原理，我们可以发现它倾向于饿死读利于写，为什么呢？异步写是把数据直接放到page cache的，也就意味着可以通过page cache缓存大量的写数据，再一次性往下提交IO请求。而读呢？读一般是同步的，也就意味着必须在读完一笔后再读下一笔，两次读之间是可能被写请求插足的。

cfq#

CFQ算法会为每个进程单独创建一个队列，保存该进程产生的所有IO请求。不同队列之间按时间片来调度，以此保证每个进程都能很好的分到I/O带宽。这IO的时间片调度跟进程调度是非常相似的，进程调度有进程优先级，而IO调度也有IO优先级。

CFQ的出发点是对IO地址进行排序，以尽量少的磁盘旋转次数来满足尽可能多的IO请求。在CFQ算法下，SAS盘的吞吐量大大提高了。但是相比于NOOP的缺点是，先来的IO请求并不一定能被满足，可能会出现饿死的情况。

当一个同步队列中的请求不足一定数量时，这个设备可以空闲一会，即使其它队列里可能有请求等待处理。通常，同步请求之间在磁盘上的物理位置是连续的，所以让磁盘稍等一会来接收更多连续的请求，这样做可以提高吞吐量。

deadline#

deadline确保请求在一个用户可配置的时间内得到响应，避免请求饿死。其分别为读IO和写IO提供不同的FIFO队列，读FIFO队列的最大等待时间是500ms，写FIFO队列的最大等待时间是5s。deadline会把提交时间相近的请求放在一批。在同一批中，请求会被排序。当一批请求达到了大小上限或着定时器超时，这批请求就会提交到设备队列上去。

选择调度算法#

网上的资料基本都给出类似的结论：

对闪存等存储介质，优先使用noop调度算法
个人PC使用cfq调度算法
对IO压力比较重，且功能比较单一的场景，例如数据库服务器，使用deadline调度算法

可惜的是网上的资料基本是相互复制，很少能讲清楚这么选择的原因。

为什么闪存等介质，例如固态硬盘SSD，要选择noop调度算法？
noop先来先处理的做法对磁盘来说时间损耗非常大，大量浪费了磁盘磁臂移动的时间。但是对闪存设备，例如mmc、nand等，却是最好的选择，因为闪存设备的物理结构跟磁盘完全不同，其通过一些规范的命令即可读取数据，没有磁臂这东西。此时IO调度算法里的排序、合并其实没太大意义，反而浪费了CPU和内存。
为什么个人PC要用cfq调度算法？
在个人PC的场景上，往往需要打开大量的程序，创建大量的进程。每个进程都可能有IO的请求。在这场景下，我们需要的是如何确保不同进程或进程组间IO资源使用的公平性。总不能因为A进程要拷贝电影，独占了IO资源，导致B进程无法打开文档不是？
cfq调度算法是以进程之间公平享用IO资源为出发点设计的，所以，个人PC建议使用cfq调度算法，但cfq调度算法不仅仅用于个人PC，准确来说，cfq调度算法适用于有大量进程的多用户系统。
为什么deadline调度算法适用于数据库？
deadline是一种以提高机械硬盘吞吐量为思考出发点的调度算法，所以准确来说，deadline调度算法适用于IO压力比较重，且业务功能单一的场景，而数据库毫无疑问是最为匹配的场景了。