概述
老幺 www.laoyao.org
由于对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压力比较重,且业务功能单一的场景,而数据库毫无疑问是最为匹配的场景了。
根据以上描述的不同调度算法的特点,我们再根据自己的场景挑选合适的IO调度算法就好,灵活点,自信点,不要别人说啥就选啥,别人没说就一脸懵逼。
多队列调度算法
先留坑,以后填