如何选择IO调度器
2020-05-08 18:54
537 查看
概述
由于对
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调度算法就好,灵活点,自信点,不要别人说啥就选啥,别人没说就一脸懵逼。
多队列调度算法
先留坑,以后填
相关文章推荐
- Mysql数据库服务器性能配置优化二 -- 文件系统及IO调度算法的选择
- IO调度选择
- [21]_如何选择合适的IO口并接上合适的外设?
- 编写简单的ramdisk(选择IO调度器)
- 浅谈linux性能调优之六:IO调度算法的选择
- 如何选择外设IO口——正点原子开发板
- 如何选择开源许可证?
- 如何选择合适的Web安全网关?
- ./ . 和#!/bin/bash 辨析Linux如何选择当前执行脚本的shell
- 如何选择股票
- 构建实时Web的JAVA选择组合:socket.io client + socketio-netty server
- 大数据:Spark Standalone 集群调度(二)如何创建、分配Executors的资源
- 百度推出高管退休计划,程序员该如何选择自己的职业生涯技术岗&管理岗?
- PS切片时,如何选择图片保存格式
- 如何选择合适的坐标系及投影
- 如何选择加密芯片?
- 在实际项目中,如何选择合适的机器学习模型?
- ABAP--如何使选择屏幕的初始化事件再次触发
- 如何选择开源许可证?
- 如何选择android app开发的方式