对IO延迟的一些思考

此文已由作者赵欣授权网易云社区发布。

欢迎访问网易云社区，了解更多网易技术产品运营经验。

任何一个系统都有两个指标和性能紧密联系：响应时间和吞吐量。就我们所维护的OTLP数据库来说，两个很关键的指标则是系统的IO延迟(响应时间)与IO吞吐量。OLTP系统最显著的特点是请求多、需要在很短的时间内给出处理结果，故而IO延迟对性能影响非常大。通俗点说就是只有IO延迟小，用户体验才会不错。

什么是IO延迟？

1个完整的I/O传输，可能会经过以下几个途径：

• 如果使用的服务器本地RAID硬盘：CPU --->内存--->RAID（SAS卡） --->硬盘
• 如果使用的是SAN存储，则为CPU --->内存--->HBA --->存储控制器--->存储硬盘

在上述I/O传输途径中消耗的时间就是IO延迟。我们习惯性的把IO的延迟分为以下几部分：

1. 系统OS等软件配置产生的延迟；
2. 硬件延迟：

• 普通本地硬盘——RAID板卡延迟、连接线延迟、硬盘自身延迟
• 外挂存储——主要包括主机延迟、链路延迟、交换机延迟、存储延迟

系统OS等软件配置产生的延迟，这种延迟很难完全准确的分析。例如：异步IO的情况下整个系统的延迟就会比同步IO下好很多，实质上这是系统OS和硬盘层面相互叠加的效果。 

	同步IO 4线程	异步直接IO 4线程
Vmstat的cpu wait	25%到40%之间	25%到40%之间
	同步IO 20线程	异步直接IO 20线程
Vmstat的cpu wait	50%到65%	30%到45%之间

可以看这样一个测试案例： 一台HP 360（1*4核，4G，4*146G HDD组raid5）使用FIO测试不同IO场景下主机性能的变化。

【随机读写、每次16K大小、持续100秒】 

可以看出IO线程数增加后同步IO的cpu可用性比之异步直接IO差很多。而cpu wait值高意味着很多线程实际上被阻塞，延迟自然就会高很多。 

硬件部分，以SAN存储系统为例，整个SAN存储系统里的硬件延迟主要包括：主机延迟、链路延迟、SAN交换机延迟、存储延迟。

• 光纤链路延迟基本上= 5ns * 距离。
• SAN交换机、主机的延迟基本上也都在1ms以内。

存储的延迟则是自身主控器+硬盘的延迟。存储主控上的缓存都比较大，加上存储厂家对命中率算法持续改进，以往单个硬盘因寻址、旋转产生的IO延迟时间都可以在一定比例上规避。大家可以看这张EMC的存储硬盘规格表：

从图中我们可以看到15K转HDD磁盘的IO延迟基本是5ms，由此得出其最大IOPS为200，那些等待事件低于5ms的存储其实都是缓存在发生作用。

对IO延迟的个人思考       

我个人更喜欢把对io延迟做这样的划分：IO延迟时间=常量延迟+变量延迟。常量就是操作系统和数据库参数配置完毕后，那些硬件上的固定延迟加上一定存储命中率下软硬件共同作用产生的延迟时间，变量延迟就是io压力变大时，特别是海量随机小IO请求，导致的延迟变大。一旦变量延迟增加的厉害，那么直观的表现就是单个业务请求完成时间增加，业务请求出现堆积，用户感觉系统很慢。以Oracle为例，我们通过awr可以看到很多IO相关的等待事件：

上图的db file seq read的平均等待时间是2.45毫秒，也就是说这个oracle内部的随机读平均IO延迟为2.45毫秒。此时oracle数据库的压力不大，这个大致就是硬件的常量延迟。

而同一个系统在业务压力较大时的随机读平均IO延迟则为7毫秒。OLTP的海量小IO读一旦没有在缓存（数据库的内存缓存和存储系统的缓存）里命中，那么就会进入到硬盘里，而这时就很容易产生变量延迟，因为大部分的IO请求都直接面向硬盘，而我们使用的机械硬盘会因为IO请求产生性能波动。我们换个主控上缓存仅为2G的低端存储，做对比： 

这个存储只要稍微IO压力上去，平均等待事件就很容易超过10ms。

所以我们对一个Oracle系统是否能抗住较大的并发查询，很多时候会看awr中IO等待事件的平均等待时间（结合IO等待事件的时间分布直方图），如果一直保持在一定范围波动，即使是很高负载，也没有变得过大，那么就是可以接受。

还需要特别指出的是，从这个等待事件的时间不能反推IOPS。因为这种IO等待很容易对应的是一个硬盘(具体要看设置的条带大小)，而存储系统的整个IOPS是所有硬盘的总IOPS+缓存命中率效应。 

也就是说对应于OLTP系统，除了看awr的等待事件，还需要看缓存效应后的IOPS总量。当然如果能够提供的IOPS总数不够，最终还是会导致每个硬盘压力过大，而从awr里体现的就是等待事件变长。

Oracle的一体机Exadata就是典型的系统+硬件结合后的高效产物，同样的等待事件甚至等待时间可以降低到1毫秒。

对IO的监控排查       

最后我们来看看系统监控层面如何来排查IO延迟。

vmstat，如果是CPU业务计算压力不大，瓶颈在IO上，我们经常可以看到vmstat的wa列很大，我在一套全国特大城市的公路售票系统都见过有30%以上。而此时这个系统的Oracle数据库awr情况如下：

这个延迟时间似乎不是很大呀，光看awr的话好像不会认为这个系统有啥IO瓶颈嘛。

其实对OLTP系统来说，因为有主机内存、存储缓存，所以独立的去看等待时间是不可取的，更何况awr是大多数时候是一个平均主义输出。比如1000个io请求500个发生延迟时间　　为20ms，另外500个因为缓存IO延迟是1ms，平均以后是10ms左右，但是实际体验却有一半的请求等待时间较长。所幸从Oracle11g开始awr报告提供等待事件相关统计时间的直方图，让我们可以更好的判断IO性能情况。有兴趣的朋友也可以读一下Thinking Clearly About Performance，里面有详细说明为何不能只用平均值来判断性能。

我习惯利用vmstat来看IO是否已经存在瓶颈，在确认cpu不存在瓶颈时，对比各种io情况，vmstat中所看到的wa基本可以很好说明存储系统的功力。

iostat和sar也是一个不错的工具命令，但是大部分人在用iostat来监控OLTP系统时关注的指标是值得商榷的。比如它的svctm和%util都有一定的问题，不建议通过它们去确认压力大小，相反await有不少参考价值。

我个人这样通过iostat和sar –d来观察系统IO情况： 

[root@test10 fio-2.1.7]# iostat -d -x 1 1
 Linux 2.6.32-431.el6.x86_64 (test10)    2014年04月14日  _x86_64_        (8 CPU)
Device:    rrqm/s   wrqm/s   r/s   w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
 cciss/c0d0   0.03    82.80    1.64    2.09   286.44   683.95   259.59     0.47  124.70   4.65   1.74
 dm-0           0.00     0.00    1.16   80.23   269.37   641.82    11.20     2.55   31.28   0.13   1.04
 dm-1           0.00     0.00    0.00    0.02     0.00     0.13     8.00     0.01  612.46   0.59   0.00
 dm-2           0.00     0.00    0.51    4.65    17.02    42.00    11.43     2.44  471.97   1.50   0.77

从avgrq-sz、avgqu-sz、await三个指标可以结合着看IO等待，比如IO队列上产生的系统延迟，如果系统读写都不是很高的情况下，这三个指标中await很高，而另外两个很低，特别是avgqu-sz，那么很可能是队列深度的配置有问题。

综上所述，我们认为每一套OLTP的数据库系统在IO方面都可以从软硬件层面去做规划和测定，硬件上线后使用orion或者其他工具做一次IO测试，Oracle安装完成后使用自带IO验证程序再做一次比对，从吞吐量、IOPS和对应的IO延迟时间这些指标对自己的系统的IO情况有个整体的掌握。

[root@test10 fio-2.1.7]# sar -d 1 3
 Linux 2.6.32-431.el6.x86_64 (test10)    2014年04月14日  _x86_64_        (8 CPU)
 22时09分22秒   DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await   svctm     %util
 22时09分23秒  dev104-0      2.02      0.00     24.24     12.00      0.02     11.00     11.00      2.22
 22时09分23秒  dev253-0      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
 22时09分23秒  dev253-1      0.00      0.00      0.00      0.00      0.00      0.00      0.00      0.00
 22时09分23秒  dev253-2      3.03      0.00     24.24      8.00      0.04     12.67      7.33      2.22

Oracle数据库因为其现有调优工具的强大，我们通过vmstat+awr其实已经可以很方便地定位IO问题。只有在前期通过orion等工具测定出极限可用IOPS和对应的延迟时间，才方便我们在后期运行过程中有个比对基准，比如线上运行中相关IO延迟显著变长，而监控发现的IOPS请求数量远远超过我们在前期的测定值，那么就需要尽快组织调优了，无论是硬件上或者系统、数据库配置上。

网易云免费体验馆，0成本体验20+款云产品！ 

更多网易技术、产品、运营经验分享请点击。