判断磁盘IO是否饱和与%util指标的意义 - 51ste.com
登录|注册

判断磁盘IO是否饱和与%util指标的意义

作者:testbird  发布时间:2019-08-21 12:17:58  关键字:%util diskbusy 

CPU饱和了很好判断,CPU利用率=100%或者接近100%就是指标。内存饱和了也很好判断,内存用光了之后持续读写swap(或者叫pagingspace)就是指标,网络IO有没有饱和看带宽利用率这个指标。那么,作为4大资源之一的磁盘IO,怎么判断是否饱和了呢?因为很多时候磁盘繁忙程度diskbusy(或者叫利用率util,或者叫活动时间)=100%的时候,系统吞吐量还可以继续增加。

存储IO的三大性能指标

首先,我们复习一下,存储IO能力的三大性能指标:IOPS、MBPS、响应时间

这里面压根就没有diskbusy。也就是说,判断存储IO能力是通过三个指标判断的,并不是这个叫做diskbusy(or util,or活动时间)的单一指标来判断的。

那么我们为什么还要讲这个指标呢?因为通过三大指标来判断是不是IO能力饱和实在是不可能的

因为,IO能力的三大指标是因读写模型的不同而不同(读写模型是指:读写比例,顺序读写or随机读写,读写size等等),你并不知道三大指标的某个数值组合是不是饱和状态,因为一般不会针对这个存储做专项的测试。用户甚至不知道自己的读写模型是什么样的,这就更谈不上专门测存储了。

磁盘繁忙程度

那么,这种情况下,怎么判断存储IO是否饱和呢?这就有了这个不靠谱的指标diskbusy(or util,or活动时间)

这个指标的官方描述:以linux系统为例

%util

Percentage of elapsed time during which I/O requests were issued to the device (bandwidth utilization for the device). Device saturation occurs when this value is close to 100% for devices serving requests serially. But for devices serving requests in parallel, such as RAID arrays and modern SSDs, this number does not reflect their performance limits.

:向设备发出I/O请求所用的时间占总时间的百分比(设备的带宽利用率)。当此值对于串行提供请求的设备接近 100% 时,会发生设备饱和。但对于并行服务请求的设备,如RAID阵列和现代SSD,这个数字并不反映它们的性能限制

我用通俗的语言解释一下,util是磁盘驱动的繁忙程度

打个比方,如果一条马路上单位时间内可以通过100辆车,我们把这个极限值定义为util=100%,那么如果单位时间内只有1辆车,util就=1%。

但每辆车上坐的人数是不确定的。同样是util=100%:

1)每辆车坐一个人,车道的运输能力就是100人/单位时间。

2)每辆车坐10个人,车道的运输能力就是1000人/单位时间。(比如10个请求或报文在一个block中被写下去,比如写日志对buffer更改十次再刷入磁盘)

另外,后来存储设备发展出array和ssd之后,马路就不止一个车道了,出现了多个车道。util仍然是按照单车道计算的。即使是util=100%,仍然可以在单位时间内通过更多的车,因为增加了车道。

我这个例子不是很贴切,磁盘的util其实是车道被占用的时间百分比,还和读写模型有关(顺序读写vs随机读写,读写比例,读写size等都会影响),对应咱们这个例子,就是有大车,有小车,有快车,有慢车。

为了让问题简单化,我们抛开多个车道的情况不管,只看单车道的情况下,什么样的情况会造成这种问题。

举例1

我们的一个系统TPS从100~500的这么大的跨度中,util始终是100%左右。原因就是block落盘的过程中,低TPS一个block写入的业务少,高TPS一个block写入的业务多。具体是怎么造成的呢?

如果出现下面两幅图的情况,就会对应上面的结果。

磁盘驱动的繁忙程度

图1

磁盘驱动的繁忙程度

图2

注:MQ在“持久模式”下必须落盘

请求的频率相同,但数量不同(图1是一次请求携带一个报文,图2 是一次请求携带5个报文),对于接收端(即服务器)每次收到请求,都要落盘。如果一个请求只有一个报文,也要一个写IO,如果一个请求是5个报文,(报文size都很小,5个报文在一个block里)也要一个写IO。因此写IO的数量是一样,IOPS相同,util相同。

那么为什么会一个请求有时包含一个报文,有时包含多个报文呢?

我们向服务器发起业务是采用消息中间件MQ,MQ有一个参数是batchsz,即一个批次的传输最多传多少个报文。这个batchsz默认是50,也就是说MQ会最多凑齐50个报文一起发过去。

如果发起端发送的频率比较低,那么单位时间内,凑不齐50个报文,也许就一次一个的发送。如果吞吐量很大,单位时间内,可以凑出好多报文,也许一次10个、20个甚至50个报文一起发。N个报文在一个block中落盘,只有一次IO。

举例2

某系统需要写日志,日志在缓存(内存)中存放,假设缓存每秒钟定时刷入磁盘。如果每秒做1个业务则写1次日志刷一次磁盘,如果每秒做100个业务则写100次日志可能还是刷一次磁盘。

这种情况想,TPS涨了100倍,但对于日志模块的IOPS是一样的。

综上

util=100%并不意味着磁盘读写能力到了瓶颈(只代表单车道到了瓶颈,不代表别的车道不能走车),也并不意味着业务系统的TPS到了瓶颈,因为业务的吞吐量(单位时间请求数)和读写磁盘的IO并不是一一对应的关系。

但util仍然是重要的性能指标,能帮助我们发现潜在的性能问题。可以为未来可能的性能问题,提供排查线索。

比如在例1中,如果因为某些原因调整了MQ的batchsz参数(报文太大、网络不稳定等因素均可以触发客户的冲动去改这个参数),将batchsz设置为1,我们发现整个系统的极限吞吐量立刻从500 TPS下降到100 TPS以下

本文由51ste.com网友编辑,未经授权,不得转载使用上述作品盈利;个人转载,需标明原文作者及出处。

更多相关文章

说说看法查看全部评论(0)

微信二维码

部落微信公众号

QQ二维码

部落QQ群二维码