Linux IO调度(电梯算法)

磁盘IO的基础原理

磁盘的组成

一块机械硬盘是由盘面、磁头和悬臂三个部件组成的。

机械磁盘
磁盘构造
  1. 盘面:是实际存储数据的盘片。盘面上有一层磁性的涂层。数据就存储在这个磁性的涂层上。 盘面中间有一个受电机控制的转轴。这个转轴会控制盘面去旋转。与盘面有关系的指标叫转速,如硬盘有5400 转的、7200 转的,乃至 10000 转的。这个多少多少转,指的就是盘面中间电机控制的转轴的旋转速度,英文单位叫RPM,也就是每分钟的旋转圈数。7200RPM,指的就是一旦电脑开机供电之后,我们的硬盘就可以一直做到每分钟转上 7200 圈。如果折算到每一秒钟,就是 120 圈。

  2. 磁头:数据并不能直接从盘面传输到总线上,而是通过磁头,从盘面上读取到,然后再通过电路信号传输给控制电路、接口,再到总线上的。通常,一个盘面上会有两个磁头,分别在盘面的正反面。盘面在正反两面都有对应的磁性涂层来存储数据,而且一块硬盘也不是只有一个盘面,而是上下堆叠了很多个盘面,各个盘面之间是平行的。每个盘面的正反两面都有对应的磁头。

  3. 悬臂:悬臂链接在磁头上,并且在一定范围内会去把磁头定位到盘面的某个特定的磁道上。

一个盘面通常是圆形的,由很多个同心圆组成,每一圈都是一个磁道。每个磁道都有自己的一个编号。悬臂其实只是控制,到底是读最里面那个圈的数据,还是最外面圈的数据

一个磁道,会分成一个一个扇区。上下平行的一个一个盘面的相同扇区呢,叫作一个柱面,读取数据,两个步骤。

  1. 把盘面旋转到某一个位置。在这个位置上,悬臂可以定位到整个盘面的某一个子区间。这个子区间的形状有点儿像一块披萨饼,一般把这个区间叫作几何扇区。意思是,在几何位置上,所有这些扇区都可以被悬臂访问到。

  2. 就是把悬臂移动到特定磁道的特定扇区,也就在这个几何扇区里面,找到我们实际的扇区。找到之后,磁头会落下,就可以读取到正对着扇区的数据。

数据存取方式

磁盘的数据读/写一般是按柱面进行的,即读/写数据时首先在同一柱面内从“0”磁头开始进行操作,依次向下在同一柱面的不同盘面即不同磁头上进行操作,只有当同一柱面所有的磁头全部读/写完毕后,磁头才转移到下一柱面(即寻道)。

因为切换磁头只需通过电子设备切换即可,而切换柱面则必须通过机械设备切换。电子磁头间的切换比机械磁头向临近磁道或柱面切换要快的多。所以,数据的读/写按柱面进行,而不按盘面进行。也就是说,一个磁道写满数据后,就在同一柱面的下一个盘面的相同半径磁道来写,一个柱面写满后,才移到下一个柱面开始写数据。读数据也按照这种方式进行,这样就大大提高了磁盘的读/写效率。

磁盘数据定位

机械硬盘的硬件,主要由盘面、磁头和悬臂三部分组成。我们的数据在盘面上的位置,可以通过磁道、扇区和柱面来定位。实际的一次对于硬盘的访问,需要把盘面旋转到某一个“几何扇区”,对准悬臂的位置。然后,悬臂通过寻道,把磁头放到我们实际要读取的扇区上。

受制于机械硬盘的结构,我们对于随机数据的访问速度,就要包含旋转盘面的平均延时和移动悬臂的寻道时间。

磁盘寻道示例

image.png

数据存放在磁盘的第六磁道的第八扇区上:

那磁头就会先摆动到第六磁道上空,然后等待第八扇区转过来。当第八扇区转到磁头下面的时候,才可以读取数据。

这就是机械硬盘的工作原理,也正是因为机械硬盘是利用磁性极粒来存储数据的,所以机械硬盘通常又被称作磁盘。

磁盘数据寻址方式

访问硬盘上的数据总是以扇区为单位进行的,即每次读或写至少是一个扇区的数据。
常用两种:物理寻址方式(CHS)和逻辑寻址方式(LBA)

物理寻址方式

物理寻址方式又称为CHS(Cylinder柱面/Head磁头/Sector扇区)方式,用柱面号(即磁道号)、磁头号(即盘面号)和扇区号来表示一个特定扇区。柱面和扇区从0开始编号,而扇区从1开始编号的。
磁盘容量=磁头数×柱面数×扇区数×512字节
系统在写入数据时是按照从柱面到柱面的方式,当上一个柱面写满数据后才移动磁头到下一个柱面,而且是从柱面的第一个磁头的第一个扇区开始写入,从而使磁盘性能最优。

逻辑寻址方式

寻址方式也改为以扇区为单位的线性寻址,这种寻址方式便是LBA。即将所有的扇区统一编号。C/H/S中的扇区编号是从“1”至“63”,而逻辑扇区LBA方式下扇区是从“0”开始编号,所有扇区编号按顺序进行。
对于任何一个硬盘,都可以认为其扇区是从0号开始。

硬盘特性

硬盘寻址时间

即完成一个io请求所花费的时间(它由寻道时间、旋转延迟和数据传输时间三部分构成)

  1. 寻道时间:磁头移动到数据所在磁道的时间

7200 rpm的硬盘平均物理寻道时间是9ms

10000 rpm的硬盘平均物理寻道时间是6ms

15000 rpm的硬盘平均物理寻道时间是4ms

  1. 旋转延迟时间:磁头移动到数据所在磁道后,数据转到磁头下的时间(旋转延迟取决于磁盘转速,通常使用磁盘旋转一周所需时间的1/2表示)

7200 rpm的磁盘平均旋转延迟大约为60*1000/7200/2 = 4.17ms

10000 rpm的磁盘平均旋转延迟大约为60*1000/10000/2 = 3ms

15000 rpm的磁盘其平均旋转延迟约为60*1000/15000/2 = 2ms

  1. 数据传输时间:忽略不计(由于磁盘是机械运动,浪费的时间主要在寻道和旋转时间上)

两部分组成了硬盘随机访问数据的时间耗费:

  1. 平均延时:这个时间,其实就是把盘面旋转,把几何扇区对准悬臂位置的时间。随机情况下,平均找到一个几何扇区,需要旋转半圈盘面。如:7200 转的硬盘,那么一秒里面,就可以旋转 240 个半圈。那么,这个平均延时就是1s / 240 = 4.17ms

  2. 平均寻道时间:也就是在盘面旋转之后,悬臂定位到扇区的的时间。现在用的 HDD 硬盘的平均寻道时间一般在 4-10ms。

所以可得,随机在整个硬盘上找一个数据,需要 8-14 ms。一块 7200 转的硬盘,一秒钟随机的 IO 访问次数,也就是1s / 8 ms = 125 IOPS 或者 1s / 14ms = 70 IOPS,符合前述HDD 硬盘的 IOPS 每秒 100 次左右。

相应的,如果不是去进行随机的数据访问,而是进行顺序的数据读写,最大化读取效率就是:我们可以选择把顺序存放的数据,尽可能地存放在同一个柱面上。这样,我们只需要旋转一次盘面,进行一次寻道,就可以去写入或者读取,同一个垂直空间上的多个盘面的数据。如果一个柱面上的数据不够,也不要去动悬臂,而是通过电机转动盘面,这样就可以顺序读完一个磁道上的所有数据。所以,其实对于 HDD 硬盘的顺序数据读写,吞吐率还是很不错的,可以达到 200MB/s 左右。

Linux IO调度(电梯算法)

https://kernel.org/

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

image.png

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

image.png

对于磁盘I/O,Linux提供了cfq, deadline和noop三种调度策略

考虑到硬件配置、实际应用场景(读写比例、顺序还是随机读写)的差异,实际该选择哪个基本还是要实测来验证。不过下面几条说明供参考:

  • deadline和noop差异不是太大,但它们俩与cfq差异就比较大。

  • MySQL这类数据存储系统不要使用cfq(时序数据库可能会有所不同)。

Deadline确保了在一个截止时间内服务请求,这个截止时间是可调整的,而默认读期限短于写期限.这样就防止了写操作因为不能被读取而饿死的现象.Deadline对数据库环境(ORACLE RAC,MYSQL等)是最好的选择。

  • 对于虚拟机上面的磁盘,建议采用比较简单的noop,毕竟数据实际上怎么落盘取决于虚拟化那一层.

NOOP算法

NOOP算法的全写为No Operation。该算法实现了最最简单的FIFO队列,所有IO请求大致按照先来后到的顺序进行操作。之所以说“大致”,原因是NOOP在FIFO的基础上还做了相邻IO请求的合并,并不是完完全全按照先进先出的规则满足IO请求。

假设有如下的io请求序列:
100,500,101,10,56,1000
NOOP将会按照如下顺序满足:
100(101),500,10,56,1000

NOOP是在Linux2.4或更早的版本的使用的唯一调度算法。由于该算法比较简单,减了IO占用CPU中的计算时间最少。不过容易造成IO请求饿死。

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

NOOP倾向饿死读而利于写.

NOOP对于闪存设备,RAM,嵌入式系统是最好的选择.(写得快,容易插队)

关于IO饿死的描述如下:因为写请求比读请求更容易。写请求通过文件系统cache,不需要等一次写完成,就可以开始下一次写操作,写请求通过合并,堆积到I/O队列中。读请求需要等到它前面所有的读操作完成,才能进行下一次读操作。在读操作之间有几毫秒时间,而写请求在这之间就到来 ,饿死了后面的读请求 。其适用于SSD或Fusion IO环境下.

Excerpt from ULK3 ch15.3

“ULK3”是“Understanding the Linux Kernel, 3rd Edition”

image.png
Unix systems allow the deferred writes of dirty pages into block devices,  
because this noticeably improves system performance. 
Several write operations  on a page in cache could be satisfied by just one slow 
physical update of the  corresponding disk sectors. Moreover, write operations
 are less critical than  read operations, 
because a process is usually not suspended due to delayed  writings, 
while it is most often suspended because of delayed reads. 
Thanks to  deferred writes, each physical block device will service,
on the average, many  more read requests than write ones.

CFQ (Complete Fairness Queueing)算法

该算法的特点是按照IO请求的地址进行排序,而不是按照先来后到的顺序来进行响应。CFQ为每个进程/线程,单独创建一个队列来管理该进程所产生的请求,也就是说每个进程一个队列,各队列之间的调度使用时间片来调度,以此来保证每个进程都能被很好的分配到I/O带宽。假设有如下的io请求序列:

100,500,101,10,56,1000
CFQ将会按照如下顺序满足:
100,101,500,1000,10,56

在传统的SAS盘上,磁盘寻道花去了绝大多数的IO响应时间。CFQ的出发点是对IO地址进行排序,以尽量少的磁盘旋转次数来满足尽可能多的IO请求。在CFQ算法下,SAS盘的吞吐量大大提高了。但是相比于NOOP的缺点是,先来的IO请求并不一定能被满足,也可能会出现饿死的情况,不过其作为最新的内核版本和发行版中默认的I/O调度器,对于通用的服务器也是最好的选择。CFQ是deadline和as调度器的折中,CFQ对于多媒体应用(video,audio)和桌面系统是最好的选择。

DEADLINE算法

DEADLINE在CFQ的基础上,解决了IO请求饿死的极端情况。除了CFQ本身具有的IO排序队列之外,DEADLINE额外分别为读IO和写IO提供了FIFO队列。读FIFO队列的最大等待时间为500ms,写FIFO队列的最大等待时间为5s。FIFO队列内的IO请求优先级要比CFQ队列中的高,而读FIFO队列的优先级又比写FIFO队列的优先级高。优先级可以表示如下:

FIFO(Read) > FIFO(Write) > CFQ

Deadline确保了在一个截止时间内服务请求,这个截止时间是可调整的,而默认读期限短于写期限。这样就防止了写操作因为不能被读取而饿死的现象。Deadline对数据库环境(ORACLE RAC,MYSQL等)是最好的选择。

ANTICIPATORY(预期)算法

CFQ和DEADLINE考虑的焦点在于满足零散IO请求上。对于连续的IO请求,比如顺序读,并没有做优化。为了满足随机IO和顺序IO混合的场景,Linux还支持ANTICIPATORY调度算法。ANTICIPATORY的在DEADLINE的基础上,为每个读IO都设置了6ms的等待时间窗口。如果在这6ms内OS收到了相邻位置的读IO请求,就可以立即满足。

本质上与Deadline一样,但在最后一次读操作后,要等待6ms,才能继续进行对其它I/O请求进行调度。可以从应用程序中预订一个新的读请求,改进读操作的执行,但以一些写操作为代价。它会在每个6ms中插入新的I/O操作,而会将一些小写入流合并成一个大写入流,用写入延时换取最大的写入吞吐量。AS适合于写入较多的环境,比如文件服务器,但对对数据库环境表现很差。

IO调度配置

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

root@harry:~# cat /sys/block/sda/queue/scheduler
noop deadline [cfq]
root@harry:/# cat /sys/block/sda/queue/scheduler 
[mq-deadline] none
root@harry:/# cat /sys/block/sda/queue/scheduler 
[mq-deadline] none

修改调度策略

root@harry:/# echo none > /sys/block/sda/queue/scheduler
root@harry:/# cat /sys/block/sda/queue/scheduler 
[none] mq-deadline 

永久修改调度策略

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

总结

CFQ和DEADLINE考虑的焦点在于满足零散IO请求上。对于连续的IO请求,比如顺序读,并没有做优化。为了满足随机IO和顺序IO混合的场景,Linux还支持ANTICIPATORY调度算法。ANTICIPATORY的在DEADLINE的基础上,为每个读IO都设置了6ms的等待时间窗口。如果在这6ms内OS收到了相邻位置的读IO请求,就可以立即满足。

IO调度器算法的选择,既取决于硬件特征,也取决于应用场景。

在传统的SAS盘上,CFQ、DEADLINE、ANTICIPATORY都是不错的选择;对于专属的数据库服务器,DEADLINE的吞吐量和响应时间都表现良好。然而在新兴的固态硬盘比如SSD、Fusion IO上,最简单的NOOP反而可能是最好的算法,因为其他三个算法的优化是基于缩短寻道时间的,而固态硬盘没有所谓的寻道时间且IO响应时间非常短。

参考文章

https://blog.csdn.net/BaiWfg2/article/details/52885287

https://kernel.org/

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

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 216,125评论 6 498
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,293评论 3 392
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 162,054评论 0 351
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,077评论 1 291
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,096评论 6 388
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,062评论 1 295
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,988评论 3 417
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,817评论 0 273
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,266评论 1 310
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,486评论 2 331
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,646评论 1 347
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,375评论 5 342
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,974评论 3 325
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,621评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,796评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,642评论 2 368
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,538评论 2 352

推荐阅读更多精彩内容