作者:朱小厮来源:https://www.jianshu.com/p/76ca793daf1d
一、概述
本篇起源于对Kafka的一个问题排查,大致的原因是达到磁盘性能瓶颈。在追踪问题的时候用到iostat -x这命令,详细示例如下:
![2f94d29adc6feccf84a6e7aa2186c1ef.png](https://i-blog.csdnimg.cn/blog_migrate/6babe08c938636ed0625afd7d88e7bae.jpeg)
可以看到%idle(%idle小于70%说明IO压力已经比较大了)和%util的值都处于非正常状态。不过这里并不讲述Kafka的问题排查过程,反而是来讲述下IO指标的一些知识。每次遇到需要查看磁盘相关信息的时候,一些指标都会或多或少的遗忘,还要翻阅各种资料了解,故这里对相关的信息做一个相关的整理,在巩固相关知识点的同时也方便以后的查阅。
上面示例中的各个指标的含义分别为:
avg-cpu说明:
%user:在用户级别运行所使用的CPU的百分比。
%nice:带nice值(和进程优先级相关)的用户模式下运行所使用的CPU的百分比。
%system:在系统级别运行所使用CPU的百分比。
%iowait:CPU等待IO完成的时间百分比。(单个iowait指标值偏高并不能说明磁盘存在IO瓶颈,下面会有详述。)
%steal:管理程序维护另一个虚拟处理器时,虚拟CPU的无意识等待时间的百分比。
%idle:CPU空闲时间的百分比。(idle值高,表示CPU较空闲。)
device说明:
rrqm/s:每秒进行merge的读操作数目。即:rmerge/s
wrqm/s:每秒进行merge的写操作数目。即:wmerge/s
r/s:每秒完成的读IO设备的次数。即rio/s
w/s:每秒完成的写IO设备的次数。即wio/s
rsec/s:每秒读扇区数。即rsect/s(每个扇区大小为512B。)
wsec/s:每秒写扇区数。即wsect/s
avgrq-sz:平均每次设备IO操作的数据大小(扇区);平均单次IO大小。
avgqu-sz:平均IO队列长度。
await:从请求磁盘操作到系统完成处理,每次请求的平均消耗时间,包括请求队列等待时间;平均IO响应时间(毫秒)。
svctm:平均每次设备IO操作的服务时间(毫秒)。
%util:一秒中有百分之多少的时间用于 I/O 操作,即被io消耗的cpu百分比。
正常情况下svctm应该是小于await值的,而svctm的大小和磁盘性能有关,CPU、内存的负荷也会对svctm值造成影响,过多的请求也会间接的导致svctm值的增加。await值的大小一般取决于svctm的值和IO队列的长度以及IO请求模式,如果scvtm比较接近await,说明IO几乎没有等待时间;如果await远大于svctm,说明IO请求队列太长,IO响应太慢,则需要进行必要优化。(可以看完下面一节再来回顾这段内容。)
如果%util接近100%,说明产生的IO请求太多,IO系统已经满负荷,该磁盘可能存在瓶颈。
队列长度(avgqu-sz)也可作为衡量系统 I/O 负荷的指标,但由于 avgqu-sz 是按照单位时间的平均值,所以不能反映瞬间的 I/O 泛洪,如果avgqu-sz比较大,则说明有大量IO在等待。
二、相关原理
对于await, svctm以及%util等,光从概念上来说,比较晦涩,可以通过下图的磁盘IO流程来加深理解:
![78f07cb5cb1b1975f806a925e9c1ed64.png](https://i-blog.csdnimg.cn/blog_migrate/edb3da7bf9f302fca5482e570b005bfa.jpeg)
(此图来源于遗产流....重新画了一遍)
磁盘IO场景
1. 用户调用标准C库进行IO操作,数据流为:应用程序buffer->C库标准IObuffer->文件系统page cache->通过具体文件系统到磁盘。
2. 用户调用文件IO,数据流为:应用程序buffer->文件系统page cache->通过具体文件系统到磁盘。
3. 用户打开文件时使用O_DIRECT,绕过page cache直接读写磁盘。
4. 用户使用类似dd工具,并使用direct参数,绕过系统cache与文件系统直接写磁盘。
发起IO请求请的步骤简析(以最长链路为例)
写操作:
1. 用户调用fwrite把数据写C库标准IObuffer后就返回,即写操作通常是个异步操作。
2. 数据到C库标准IObuffer后,不会立即刷新到磁盘,会将多次小数据量相邻写操作先缓存起来合并,最终调用write函数一次性写入(或者将大块数据分解多次write调用)page cache。
3. 数据到page cache后也不会立即刷新到磁盘,内核有pdflush线程在不停的检测脏页,判断是否要写回到磁盘中,如果是则发起磁盘IO请求。
读操作:
1. 用户调用fread到C库标准IObuffer读取数据,如果成功则返回,否则继续。
2. 到page cache读取数据,如果成功则返回,否则继续。
3. 发起IO请求,读取到数据后缓存buffer和C库标准IObuffer并返回。可以看出,读操作是同步请求。
IO请求处理
1. 通用块层根据IO请求构造一个或多个bio结构并提交给调度层。bio结构描述对一个磁盘扇区读/写操作。
2. 调度器将bio结构进行排序和合并组织成队列且确保读写操作尽可能理想:将一个或多个进程的读操作合并到一起读,将一个或多个进程的写操作合并到一起写,尽可能变随机为顺序(因为随机读写比顺序读写要慢),读必须优先满足,而写也不能等太久。
IO调度算法
Linux的IO调度器有时也称之为磁盘调度器,工作机制是控制块设备的请求队列,确定队列中那些IO的优先级更高以及何时下发IO到块设备,以此来减少磁盘寻到时间,从而提高系统的吞吐量。目前Linux共有如下几种IO调度算法:
1. NOOP
NOOP算法的全写为No Operation。该算法实现了最最简单的FIFO队列,所有IO请求大致按照先来后到的顺序进行操作。之所以说“大致”,原因是NOOP在FIFO的基础上还做了相邻IO请求的合并,并不是完完全全按照先进先出的规则满足IO请求。
假设有如下的io请求序列:
100,500,101,10,56,1000
NOOP将会按照如下顺序满足:
100(101),500,10,56,1000
2、CFQ
CFQ算法的全写为Completely Fair Queuing。该算法的特点是按照IO请求的地址进行排序,而不是按照先来后到的顺序来进行响应。
假设有如下的io请求序列:
100,500,101,10,56,1000
CFQ将会按照如下顺序满足:
100,101,500,1000,10,56
CFQ是默认的磁盘调度算法,对于通用服务器来说最好的选择。它视图均匀地分布对IO带宽的访问。CFQ为每个进程单独创建一个队列来管理该进程所产生的请求,也就是说每个进程一个队列,各队列之间的调度使用时间片来调度,以此来保证每个进程都能被很好的分配到IO带宽。IO调度器每次执行一个进程的4次请求。在传统的SAS盘上,磁盘寻道花去了绝大多数的IO响应时间。CFQ的出发点是对IO地址进行排序,以尽量少的磁盘旋转次数来满足尽可能多的IO请求。在CFQ算法下,SAS盘的吞吐量大大提高了。但是相比于NOOP的缺点是,先来的IO请求并不一定能被满足,可能会出现饿死的情况。
3、DEADLINE
DEADLINE在CFQ的基础上,解决了IO请求饿死的极端情况。除了CFQ本身具有的IO排序队列之外,DEADLINE额外分别为读IO和写IO提供了FIFO队列。读FIFO队列的最大等待时间为500ms,写FIFO队列的最大等待时间为5s。FIFO队列内的IO请求优先级要比CFQ队列中的高,而读FIFO队列的优先级又比写FIFO队列的优先级高。优先级可以表示如下:
FIFO(Read) > FIFO(Write) > CFQ
4、ANTICIPATORY
CFQ和DEADLINE考虑的焦点在于满足零散IO请求上。对于连续的IO请求,比如顺序读,并没有做优化。为了满足随机IO和顺序IO混合的场景,Linux还支持ANTICIPATORY调度算法。ANTICIPATORY的在DEADLINE的基础上,为每个读IO都设置了6ms的等待时间窗口。如果在这6ms内OS收到了相邻位置的读IO请求,就可以立即满足。 anticipatory 算法通过增加等待时间来获得更高的性能,假设一个块设备只有一个物理查找磁头(例如一个单独的SATA硬盘),将多个随机的小写入流合并成一个大写入流(相当于给随机读写变顺序读写),使用这个原理来使用读取写入的延时换取最大的读取写入吞吐量.适用于大多数环境,特别是读取写入较多的环境。
不同的磁盘调度算法(以及相应的IO优化手段)对Kafka这类依赖磁盘运转的应用的影响很大,建议根据不同的业务需求来测试选择合适的磁盘调度算法(以后的文章中会有相关的测试介绍)。
查看设备当前的IO调度器:cat /sys/block/{DEVICE-NAME}/queue/scheduler。其中{DEVICE-NAME}指的是磁盘设备的名称,即文章开头iostat -x中Device下方的vda,vdb等。
举例:
[root@hidden ~]# cat /sys/block/vda/queue/schedulernoop anticipatory deadline [cfq]
修改当前的IO调度器: echo {SCHEDULER-NAME} > /sys/block/{DEVICE-NAME}/queue/scheduler。其中{SCHEDULER-NAME}取值为noop、anticipatory、deadline、cfq其中之一。
举例:
[root@hidden ~]# echo noop > /sys/block/vda/queue/scheduler [root@hidden ~]# cat /sys/block/vda/queue/scheduler[noop] anticipatory deadline cfq
以上设置重启之后会失效,如果要想重启后配置仍然生效,需要在内核启动参数中将elevator={SCHEDULER-NAME}写入/boot/grub/menu.lst文件中。在修改这个文件之前最好先备份一份,然后将elevator={SCHEDULER-NAME}添加到文件末尾即可。
三、iowait
单独拎出iowait来说明是因为很多人对这个指标有一定的误区,包括笔者也经常把iowait和await混淆起来
。顾名思义,就是系统因为io导致的进程wait。再深一点讲就是:这时候系统在做IO,导致没有进程在干活,cpu在执行idle进程空转,所以说iowait的产生要满足两个条件,一是进程在等IO,二是等IO时没有进程可运行。
常用的top命令中也有iowait的指标展示(%wa就是%iowait),示例如下:
![479936525676e4e79e1b9204c3002812.png](https://i-blog.csdnimg.cn/blog_migrate/3e26290c9d3b66f4172ed983e74b884e.jpeg)
对 iowait 常见的误解有两个:1. 误以为 iowait 表示CPU不能工作的时间;2. 误以为 iowait 表示I/O有瓶颈问题。
iowait 的首要条件就是CPU空闲,既然空闲当然就可以接受运行任务,只是因为没有进程可以运行,CPU才进入空闲状态的。那为什么没有进程可以运行呢?因为进程都处于休眠状态、在等待某个特定事件:比如等待定时器、或者来自网络的数据、或者键盘输入、或者等待I/O操作完成,等等。iowait的升高并不能证明等待IO进程的数量增多了,也不能证明等待IO的总时间增加了。例如,在CPU繁忙期间发生的I/O,无论IO是多还是少,iowait都不会变;当CPU繁忙程度下降时,有一部分IO落入CPU空闲时间段内,导致iowait升高。再比如,IO的并发度低,iowait就高;IO的并发度高,iowait可能就比较低。所以iowait 所含的信息量非常少,它是一个非常模糊的指标,如果看到 iowait 升高,还需检查I/O量有没有明显增加,相应的一些指标有没有明显增大,应用有没有感觉变慢,如果都没有,就没什么好担心的。
Plus: 可以使用iotop命令来查找引起高iowait对应的进程。查看CPU使用率及负载的一些命令有:top、vmstat、mpstat、uptime等。