Linux IO Scheduler

　　一直都对linux的io调度算法不理解，这段时间一直都在看这方面的内容，下面是总结和整理的网络上面的内容。生产上如何建议自己压一下。以实际为准。

　　每个块设备或者块设备的分区，都对应有自身的请求队列(request_queue),而每个请求队列都可以选择一个I/O调度器来协调所递交的request。I/O调度器的基本目的是将请求按照它们对应在块设备上的扇区号进行排列，以减少磁头的移动，提高效率。每个设备的请求队列里的请求将按顺序被响应。实际上，除了这个队列，每个调度器自身都维护有不同数量的队列，用来对递交上来的request进行处理，而排在队列最前面的request将适时被移动到请求队列中等待响应。

　　   IO调度器在内核栈中所处位置如下：

　　

　　下图是一个以write为例的 Linux 磁盘IO子系统的架构：

　　下面是详细的Linux 存储栈流程图：

　　

IO调度器的总体目标是希望让磁头能够总是往一个方向移动,移动到底了再往反方向走,这恰恰就是现实生活中的电梯模型,所以IO调度器也被叫做电梯. (elevator)而相应的算法也就被叫做电梯算法.而Linux中IO调度的电梯算法有好几种,一个叫做as(Anticipatory),一个叫做 cfq(Complete Fairness Queueing),一个叫做deadline,还有一个叫做noop(No Operation).具体使用哪种算法我们可以在启动的时候通过内核参数elevator来指定.

1、I/O调度的4种算法：

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

特点:

在最新的内核版本和发行版中,都选择CFQ做为默认的I/O调度器,对于通用的服务器也是最好的选择.

CFQ试图均匀地分布对I/O带宽的访问,避免进程被饿死并实现较低的延迟,是deadline和as调度器的折中.

CFQ对于多媒体应用(video,audio)和桌面系统是最好的选择.

CFQ赋予I/O请求一个优先级,而I/O优先级请求独立于进程优先级,高优先级的进程的读写不能自动地继承高的I/O优先级.

 

工作原理:

CFQ为每个进程/线程,单独创建一个队列来管理该进程所产生的请求,也就是说每个进程一个队列,各队列之间的调度使用时间片来调度,

以此来保证每个进程都能被很好的分配到I/O带宽.I/O调度器每次执行一个进程的4次请求.

 

 

2)NOOP(电梯式调度程序)

特点:

在Linux2.4或更早的版本的调度程序,那时只有这一种I/O调度算法.

NOOP实现了一个简单的FIFO队列,它像电梯的工作主法一样对I/O请求进行组织,当有一个新的请求到来时,它将请求合并到最近的请求之后,以此来保证请求同一介质.

NOOP倾向饿死读而利于写.

NOOP对于闪存设备,RAM,嵌入式系统是最好的选择.

电梯算法饿死读请求的解释:

因为写请求比读请求更容易.

写请求通过文件系统cache,不需要等一次写完成,就可以开始下一次写操作,写请求通过合并,堆积到I/O队列中.

读请求需要等到它前面所有的读操作完成,才能进行下一次读操作.在读操作之间有几毫秒时间,而写请求在这之间就到来,饿死了后面的读请求.

 

 

3)Deadline(截止时间调度程序)

特点:

　  Deadline算法的核心在于保证每个IO请求在一定的时间内一定要被服务到，以此来避免某个请求饥饿。

Deadline算法中引入了四个队列，这四个队列可以分为两类，每一类都由读和写两类队列组成，一类队列用来对请求按起始扇区序号进行排序，通过红黑树来组织，称为sort_list；另一类对请求按它们的生成时间进行排序，由链表来组织，称为fifo_list。每当确定了一个传输方向(读或写)，那么将会从相应的sort_list中将一批连续请求dispatch到requst_queue的请求队列里，具体的数目由fifo_batch来确定。只有下面三种情况才会导致一次批量传输的结束：

1）对应的sort_list中已经没有请求了

2）下一个请求的扇区不满足递增的要求

3）上一个请求已经是批量传输的最后一个请求了。

所有的请求在生成时都会被赋上一个期限值(根据jiffies)，并按期限值排序在fifo_list中，读请求的期限时长默认为为500ms，写请求的期限时长默认为5s，可以看出内核对读请求是十分偏心的，其实不仅如此，在deadline调度器中，还定义了一个starved和writes_starved，writes_starved默认为2，可以理解为写请求的饥饿线，内核总是优先处理读请求，starved表明当前处理的读请求批数，只有starved超过了writes_starved后，才会去考虑写请求。因此，假如一个写请求的期限已经超过，该请求也不一定会被立刻响应，因为读请求的batch还没处理完，即使处理完，也必须等到starved超过writes_starved才有机会被响应。为什么内核会偏袒读请求？这是从整体性能上进行考虑的。读请求和应用程序的关系是同步的，因为应用程序要等待读取的内容完毕，才能进行下一步工作，因此读请求会阻塞进程，而写请求则不一样，应用程序发出写请求后，内存的内容何时写入块设备对程序的影响并不大，所以调度器会优先处理读请求。

默认情况下，读请求的超时时间是500ms，写请求的超时时间是5s。

The main goal of the Deadline scheduler is to guarantee a start service time for a request.^[1] It does so by imposing a deadline on all I/O operations to prevent starvation of requests. It also maintains two deadline queues, in addition to the sorted queues (both read and write). Deadline queues are basically sorted by their deadline (the expiration time), while the sorted queues are sorted by the sector number.

Before serving the next request, the deadline scheduler decides which queue to use. Read queues are given a higher priority, because processes usually block on read operations. Next, the deadline scheduler checks if the first request in the deadline queue has expired. Otherwise, the scheduler serves a batch of requests from the sorted queue. In both cases, the scheduler also serves a batch of requests following the chosen request in the sorted queue.

By default, read requests have an expiration time of 500 ms, write requests expire in 5 seconds.

4)AS(预料I/O调度程序)

Anticipatory算法的核心是局部性原理，它期望一个进程做完一次IO请求后还会继续在此处做IO请求。在IO操作中，有一种现象叫“假空闲”（Deceptive idleness），它的意思是一个进程在刚刚做完一波读操作后，看似是空闲了，不读了，但是实际上它是在处理这些数据，处理完这些数据之后，它还会接着读，这个时候如果IO调度器去处理另外一个进程的请求，那么当原来的假空闲进程的下一个请求来的时候，磁头又得seek到刚才的位置，这样大大增加了寻道时间和磁头旋转时间。所以，Anticipatory算法会在一个读请求做完后，再等待一定时间t（通常是6ms），如果6ms内，这个进程上还有读请求过来，那么我继续服务，否则，处理下一个进程的读写请求。

在一些场景下，Antocipatory算法会有非常有效的性能提升。这篇文章有说，这篇文章也有一份评测。

值得一提的是，Anticipatory算法从Linux 2.6.33版本后，就被移除了，因为CFQ通过配置也能达到Anticipatory算法的效果。

 

2、修改io调度算法

 

查看当前系统支持的IO调度算法

dmesg | grep -i scheduler
[root@localhost ~]# dmesg | grep -i scheduler
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)

查看当前系统的I/O调度方法:

cat /sys/block/sda/queue/scheduler
noop anticipatory deadline [cfq]

临地更改I/O调度方法:

例如:想更改到noop电梯调度算法:

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

想永久的更改I/O调度方法:

修改内核引导参数,加入elevator=调度程序名

vi /boot/grub/menu.lst
更改到如下内容:
kernel /boot/vmlinuz-2.6.-.el5 ro root=LABEL=/ elevator=deadline rhgb quiet

重启之后,查看调度方法:

cat /sys/block/sda/queue/scheduler
noop anticipatory [deadline] cfq

已经是deadline了。

3、一些磁盘相关的内核参数

/sys/block/sda/queue/nr_requests 磁盘队列长度。默认只有 128 个队列,可以提高到 512 个.会更加占用内存,但能更加多的合并读写操作,速度变慢,但能读写更加多的量

/sys/block/sda/queue/iosched/antic_expire 等待时间 。读取附近产生的新请时等待多长时间

/sys/block/sda/queue/read_ahead_kb

    这个参数对顺序读非常有用,意思是,一次提前读多少内容,无论实际需要多少.默认一次读 128kb 远小于要读的,设置大些对读大文件非常有用,可以有效的减少读 seek 的次数,这个参数可以使用 blockdev –setra 来设置,setra 设置的是多少个扇区,所以实际的字节是除以2,比如设置 512 ,实际是读 256 个字节.

 

/proc/sys/vm/dirty_ratio

这个参数控制文件系统的文件系统写缓冲区的大小,单位是百分比,表示系统内存的百分比,表示当写缓冲使用到系统内存多少的时候,开始向磁盘写出数 据.增大之会使用更多系统内存用于磁盘写缓冲,也可以极大提高系统的写性能.但是,当你需要持续、恒定的写入场合时,应该降低其数值,一般启动上缺省是 10.下面是增大的方法：

echo >  /proc/sys/vm/dirty_background_ratio

这个参数控制文件系统的pdflush进程,在何时刷新磁盘.单位是百分比,表示系统内存的百分比,意思是当写缓冲使用到系统内存多少的时候, pdflush开始向磁盘写出数据.增大之会使用更多系统内存用于磁盘写缓冲,也可以极大提高系统的写性能.但是,当你需要持续、恒定的写入场合时,应该降低其数值,一般启动上缺省是 5.下面是增大的方法：

 echo  >  /proc/sys/vm/dirty_writeback_centisecs

这个参数控制内核的脏数据刷新进程pdflush的运行间隔.单位是 1/100 秒.缺省数值是500,也就是 5 秒.如果你的系统是持续地写入动作,那么实际上还是降低这个数值比较好,这样可以把尖峰的写操作削平成多次写操作.设置方法如下： echo ‘200’ > /proc/sys/vm/dirty_writeback_centisecs 如果你的系统是短期地尖峰式的写操作,并且写入数据不大（几十M/次）且内存有比较多富裕,那么应该增大此数值：

echo  > /proc/sys/vm/dirty_writeback_centisecs

/proc/sys/vm/dirty_expire_centisecs

这个参数声明Linux内核写缓冲区里面的数据多“旧”了之后,pdflush进程就开始考虑写到磁盘中去.单位是 1/100秒.缺省是 30000,也就是 30 秒的数据就算旧了,将会刷新磁盘.对于特别重载的写操作来说,这个值适当缩小也是好的,但也不能缩小太多,因为缩小太多也会导致IO提高太快.建议设置为 1500,也就是15秒算旧.

echo  > /proc/sys/vm/dirty_expire_centisecs

当然,如果你的系统内存比较大,并且写入模式是间歇式的,并且每次写入的数据不大（比如几十M）,那么这个值还是大些的好.

总结：

　　选用何种io调度算法，还是以实际情况为准，因为io的情况，不止单单io调度的问题，它还和Linux预读大小，raid类型，操作系统版本，linux内核版本，数据量和访问量有关，

自己做了很简陋的压测，不同的Linux预读大小，数据库的tps也是不同的，而且随着linux内核的不断更新，io调度算法也许不断的在优化。一切都以实际为准。

参考资料：

http://www.cnblogs.com/cobbliu/p/5389556.html

http://blog.163.com/digoal@126/blog/static/1638770402015117214118/

http://www.cnblogs.com/digdeep/p/4863502.html

https://www.postgresql.org/message-id/flat/FF5CEB38-D75C-4D97-A121-988452B55BFD%40richrelevance.com#FF5CEB38-D75C-4D97-A121-988452B55BFD@richrelevance.com

https://en.wikipedia.org/wiki/I/O_scheduling

https://www.thomas-krenn.com/en/wiki/Linux_Storage_Stack_Diagram

https://en.wikipedia.org/wiki/Deadline_scheduler

https://en.wikipedia.org/wiki/CFQ

https://www.percona.com/blog/2009/01/30/linux-schedulers-in-tpcc-like-benchmark/

https://blog.pgaddict.com/posts/postgresql-with-different-io-schedulers

https://blog.pgaddict.com/posts/postgresql-io-schedulers-cfq-noop-deadline

https://www.kernel.org/doc/Documentation/block/deadline-iosched.txt