Linux I/O调度策略

I/O scheduler的作用就是为上层应用发过来的IO请求做一个优化，它主要完成两件事：merge and sort。以此达到提高系统吞吐量、缩短响应时间的目的。为什么要merge and sort，因为在机械磁盘时代寻道时间的代价很大，如果能对相邻物理地址的请求顺序做优化那么可以大大的提高读写性能。

更改I/O scheduler有两种方式：

1./sys/block/device_name/queue/scheduler (IOscheduler); /sys/block/device_name/queue/nr_request(queuesize)

2.永久修改？启动时，grup->edit->elevator =scheduler_name

但是提高系统吞吐量和缩短响应时间是一件矛盾的事情。因为如果为了提高系统吞吐量，则必然要对IO请求的某些顺序做改变，这就导致了某些IO请求的响应时间增大。而如果为了减小响应时间（那么就是来一个请求响应一个）那么系统吞吐量或许就会降低了。因此linux有了四种I/O scheduler来满足不同的情况。

1.CFQ(completely fair queuing)

完全公平队列，实现了请求的sort和merge。每个进程的IO请求产生一个队列，这个队列是对寻道地址进行排序，尽量减少寻道时间。每个进程的队列有自己的优先级，然后以时间片轮转的方式去服务每个进程的请求队列，但是CFQ有一个劣势---会存在请求响应时间很长或者被饿死的情况。[1]

2.Deadline

deadline是为了解决请求响应时间太长，被饿死这种情况而出现的。它也实现了请求的sort和merge，然后为每个请求分配一个超期时间，这样就避免了某个请求被饿死的情况。在它的实现中有三种队列标准的sort queue（按照寻道地址进行排序和合并的请求队列），read queue（读请求队列），write queue（写请求队列），其中read queue的优先级比write queue的优先级高，这主要是因为用户发出了读请求后会立马等待结果，而用户发出了写请求后则不会等待他是否完成了（因为用户看不到）。这三者的优先级关系是Q(read)
> Q(write) > Q(deadline)。deadline中大概处理流程是这样的：当一个请求从上层应用发送过来首先往标准的sort queue中放，然后根据它是read或者write放入对应的read queue或者write queue并同时为这个请求添加一个截止响应时间；当一个取下一个请求进行响应时首先从sort queue中取出，但是如果此时read queue或者write queue里面有截止服务时间到了的请求，那么优先从read queue或者write queue中取出请求来服务。但是我们需要注意一点的时这里的deadline并不是绝对的在截止时间内一定会被服务，举个最简单的例子，一瞬间有非常多的请求都到截止时间，而请求的响应确实有先后顺序的。所以说deadline是一种保证请求几乎在截止时间内会被服务的IO调度器。

3.NOOP

NOOP的全称是no operations，它就是一个简单的FIFO，不过它实现了merge（没有sort），也就是说如果两个请求访问的额磁道地址在一起，那么就会合并它们。这种适用于寻道时间极小或者没有所谓的寻道时间代价的存储设备，比如说SSD、fusion IO，而不适应HDD。

4.AS

AS其实和CFQ差不蛮多，称作预期的调度，别的IO scheduler都只是对离散IO做了优化但是并没有对连续IO作优化，比如说一个IO请求刚执行完的这瞬间又在此位置来了一个IO请求，那么在AS这种情况下就可以马上响应刚才新来的那个请求，它是通过每次完成之后等那么极短的时间来响应的（6ms？）不过现在已经被CFQ取代。简单的说：CFQ是一种通用方案，deadline适用对响应要求高的情景，而NOOP适用SSD、fusion IO。但是具体的也要看实际情况，比如说deadline只有在极大地IO情况下才有可能提升一定的性能（自己做过测试，规模比较小，没有多大性能提升）

下面在谈谈queue size

Queue size就是用来存在IO请求的队列的大小，所以理论上来说queue size越大，提升的性能更大，因为有更多的请求被优化了。但是这里需要注意几种情况。

1. 在SSD、Fusion IO这种不需要寻道时间（seek time）的情景下，增大了size并没有多大益处，或许会因为对队列的维护而带来负面影响。所以使用之前最好还是测试一下比较合适。

2. 在使用innodb的时候，无论是CFQ还是deadline，都不要设置为太大的queue size。有人说innodb内部也对io请求做了根os一样的优化（实际上应该指的就是insert buffer），那么如果在os层把queue size设得太大的话会与innodb内部重复，导致额外的代价，性能或许会更低（其实这里我有一个疑问，innodb内部在做IO请求合并时是根据什么标准来合并排序的呢？比如LBA？或是真正的物理地址CHS？）。

3. Linux的文档中说deadline比CFQ更适合数据库这种情况，但是貌似只有在极大地系统压力情况下deadline才会比CFQ有比较大的性能优势。

参考文章：

[1] http://www.mjmwired.net/kernel/Documentation/block/cfq-iosched.txt
[2] http://yoshinorimatsunobu.blogspot.com/2009/04/linux-io-scheduler-and-queue-size.html