发布于2021-03-14 05:47 阅读(857) 评论(0) 点赞(10) 收藏(0)
大家都知道硬盘的随机IO很慢,但是比顺序IO慢多少呢,不知道你是否有过数字上的直接对比。今天我来实际压测对比一下磁盘在顺序IO和随机IO不同场景下的性能数据表现。通过今天的实验数据,你将能深刻理解数据库事务中为什么要用日志的方式来实现,为什么索引中要用节点更大的B+树。
对于任何存储系统,性能指标无非就是带宽、延迟或IOPS。我的测试机器的硬盘配置是一个由7块300G万转机械磁盘组成的RAID5,压测工具使用的fio,压测过程中,我们固定几个参数:
然后再对另外的参数进行动态调整,然后进行多次对比测试
我们先来看一下顺序读取情况下,在该磁盘阵列的带宽表现,见图1:
可以看到,当IO size比较小的时候,即使是顺序发起连续IO请求,带宽表现也不算给力,只有不到20MB/s。随着IO size增加的时候,带宽也上来了,最大能够达到1.2GB多。
大家注意看下在NORA情况下,在128K增加到256K的时候,带宽突然增加了很多,这是为啥呢?秘密在于我的RAID阵列里的条带大小是128K,当IO size为256K的时候,磁盘阵列才开始真正并行工作了。IO size小的时候,并不能发挥多盘优势。
/opt/MegaRAID/MegaCli/MegaCli64 -LDInfo -Lall -aALL
......
Strip Size : 128 KB
另外就是对于顺序IO的情况,RA预取也能起到一些作用,在IO size在64k的时候就能够达到1.2GB的带宽。
我们再来看延迟,见图2:
我们图中的单位是微秒-us,在《简单聊聊磁盘分区》中,我对磁盘耗时进行过理论上的估算,磁盘耗时主要在两个地方:
为什么在图2实验结果里,延时却都很低,在IO size为512的时候,平均竟然只有30us左右?其实顺序IO的情况下,RAID卡缓存命中率很高,其实绝大部分的读请求并没有穿透到让磁盘的机械轴来工作。
我们再来看IOPS,见图3:
在IO请求size正好为1个扇区大小的时候,磁盘阵列的IOPS表现最高,达到了3W多次每秒。当IO size增加的时候,IOPS在逐步下降,但这时候,其实磁盘的吞吐是在增加的。
汇总一下,磁盘阵列在顺序IO的情况下表现还是很不错的,原因有三个:
我们作为开发者使用磁盘的时候,可能不一定能保证永远都能让它工作在最舒服的状态,有些时候可能也必须得让它进行随机访问。所以我们今天也试一下我的磁盘阵列在随机情况下的表现,对于fio工具来说只需要设置rw参数为randread既可。不过IO size我只测试到了128就停了,因为再大了就越像顺序IO了。
我们还是先来看带宽,见图4:
机械硬盘即使是组成了RAID阵列,而且还有缓存,貌似对随机IO也无可奈何。在随机IO的情况下,带宽吞吐糟糕透了,在IO size比较小的时候,竟然只有零点几兆每秒。
我们再来看延时,见图5:
随机情况下延时基本都5ms左右,这就和我们前面理论上的计算结果对上了。随机访问导致更多的请求真正穿透到了机械轴上。
再来看IOPS,这个指标也很差,也就是200左右吧。这个数据和图5的延迟形成了呼应,处理一次请求5ms左右,那么1秒可不就是只能处理200次左右么。所以硬盘厂家们天天给你吹风,说他家磁盘IOPS能达到几万几万。但是他们从来闭口不提随机IO情况下,其实特么的只有200。
大家看到了我的万转机械硬盘组成RAID5阵列,在顺序条件最好的情况下,带宽可以达到1GB/s以上,平均延时也非常低,最低只有20多us。但是在随机IO的情况下,机械硬盘的短板就充分暴露了,零点几兆的带宽,将近5ms的延迟,IOPS只有200左右。其原因是因为
理解了磁盘顺序IO时候的几十M甚至一个GB的带宽,随机IO这个真的是太可怜了。
从上面的测试数据中我们看到了机械硬盘在顺序IO和随机IO下的巨大性能差异。在顺序IO情况下,磁盘是最擅长的顺序IO,再加上Raid卡缓存命中率也高。这时带宽表现有几十、几百M,最好条件下甚至能达到1GB。IOPS这时候能有2-3W左右。 到了随机IO的情形下,机械轴也被逼的跳来跳去寻道,RAID卡缓存也失效了。带宽跌到了1MB以下,最低只有100K,IOPS也只有可怜巴巴的200左右。
如果你真正理解了以上实验中的数据,就能理解很多工程实践中的许多的事情。
复制文件夹:我们都知道,在复制一个文件夹的时候,如果这个文件夹里面包含了许多堆碎文件,这时候复制起来非常慢。原因就是这时候机械硬盘大概率都是在随机IO。怎么提高复制速度呢?很简单,就是把它们先打一个包。打包之后这个文件夹就变成一个大文件了,这时候再复制的话,磁盘就是执行的最擅长的顺序IO了,所以会快很多。
数据库事务:所有的数据库在实现事务的时候,都要保证写数据落盘成功才能返回。但为什么他们几乎都是落盘到自己的事务日志文件里去就返回成功的,而不是直接写入到数据表文件里。这背后的原因还是磁盘读写性能问题,事务只需要保证数据落地成功就可以,至于写到哪里并不重要。写到数据文件中的话大概率就变成随机IO了。如果写到一个日志文件中,就是地地道道的顺序IO,性能就发挥到极致。
Mysql的B+树:在上面的数据中大家还可以看到,无论是顺序IO还是随机IO,只要增加每次IO的单位,性能都会上涨。理解了这个,你就能真正理解为什么Mysql是采用B+树当索引,而不是用其它的树了(比如二叉树)。因为B+树的节点更大,IO起来会让磁盘工作更舒服一些。
最后结尾我想分享一个5年前我在工程中实际性能优化的案例。当时接手了一个系统,要用数以百万级的用户imei,到Mysql中去查询用户的另一个字符串id(clientid)数据。前开发的实现方式是传统的分批进行Mysql语句查询。这种实现下,且不说多次的网络RTT耗时,单说Mysql查询,即使是有索引这时候也得需要进行大量的随机IO,因为用户imei是随机分布的。我采用的优化方式也非常简单,直接把Mysql用户整张用户表一次性通过顺序IO的方式读出来,load到内存中。在内存中用HashTable组织好,通过Hash的方式进行快速查询。最终耗时优化掉了90%以上。
开发内功修炼之硬盘篇专辑:
我的公众号是「开发内功修炼」,在这里我不是单纯介绍技术理论,也不只介绍实践经验。而是把理论与实践结合起来,用实践加深对理论的理解、用理论提高你的技术实践能力。欢迎你来关注我的公众号,也请分享给你的好友~~~
原文链接:https://www.cnblogs.com/kfngxl/p/13935079.html
作者:phpNumOne
链接:http://www.phpheidong.com/blog/article/3014/eb822deff240ec0954d4/
来源:php黑洞网
任何形式的转载都请注明出处,如有侵权 一经发现 必将追究其法律责任
昵称:
评论内容:(最多支持255个字符)
---无人问津也好,技不如人也罢,你都要试着安静下来,去做自己该做的事,而不是让内心的烦躁、焦虑,坏掉你本来就不多的热情和定力
Copyright © 2018-2021 php黑洞网 All Rights Reserved 版权所有,并保留所有权利。 京ICP备18063182号-4
投诉与举报,广告合作请联系vgs_info@163.com或QQ3083709327
免责声明:网站文章均由用户上传,仅供读者学习交流使用,禁止用做商业用途。若文章涉及色情,反动,侵权等违法信息,请向我们举报,一经核实我们会立即删除!