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种算法：
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算法的效果。
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)
cat /sys/block/sda/queue/scheduler noop anticipatory deadline [cfq]
echo noop > /sys/block/sda/queue/scheduler
vi /boot/grub/menu.lst 更改到如下内容: kernel /boot/vmlinuz-2.6.18-8.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 等待时间 。读取附近产生的新请时等待多长时间
这个参数控制文件系统的文件系统写缓冲区的大小,单位是百分比,表示系统内存的百分比,表示当写缓冲使用到系统内存多少的时候,开始向磁盘写出数 据.增大之会使用更多系统内存用于磁盘写缓冲,也可以极大提高系统的写性能.但是,当你需要持续、恒定的写入场合时,应该降低其数值,一般启动上缺省是 10.下面是增大的方法：
echo 40> /proc/sys/vm/dirty_background_ratio
这个参数控制文件系统的pdflush进程,在何时刷新磁盘.单位是百分比,表示系统内存的百分比,意思是当写缓冲使用到系统内存多少的时候, pdflush开始向磁盘写出数据.增大之会使用更多系统内存用于磁盘写缓冲,也可以极大提高系统的写性能.但是,当你需要持续、恒定的写入场合时,应该降低其数值,一般启动上缺省是 5.下面是增大的方法：
echo 20 > /proc/sys/vm/dirty_writeback_centisecs
这个参数控制内核的脏数据刷新进程pdflush的运行间隔.单位是 1/100 秒.缺省数值是500,也就是 5 秒.如果你的系统是持续地写入动作,那么实际上还是降低这个数值比较好,这样可以把尖峰的写操作削平成多次写操作.设置方法如下： echo ‘200’ > /proc/sys/vm/dirty_writeback_centisecs 如果你的系统是短期地尖峰式的写操作,并且写入数据不大（几十M/次）且内存有比较多富裕,那么应该增大此数值：
echo 1000 > /proc/sys/vm/dirty_writeback_centisecs
/proc/sys/vm/dirty_expire_centisecs
这个参数声明Linux内核写缓冲区里面的数据多“旧”了之后,pdflush进程就开始考虑写到磁盘中去.单位是 1/100秒.缺省是 30000,也就是 30 秒的数据就算旧了,将会刷新磁盘.对于特别重载的写操作来说,这个值适当缩小也是好的,但也不能缩小太多,因为缩小太多也会导致IO提高太快.建议设置为 1500,也就是15秒算旧.
echo 1500 > /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
posted on 2017-09-25 15:58 Still water run deep 阅读(523) 评论(0) 编辑 收藏 举报
