上下观古今,起伏千万途。这篇文章主要讲述存储性能测试漫谈相关的知识,希望能为你提供帮助。
对于存储性能测试,一般有两种方法:
1.
使用业内比较认可的性能测试工具,比如IOMeter、fio、iozone等。这类工具一般是开源的,应用范围很广泛,使用它们的一个好处是可以快速和其他存储产品做横向对比。哪怕大家是在不同时间、不同地点、不同环境测试的,但只要参数设置差不多,就可以拿来简单对比(如果要做完整对比,必须放在同样的环境中测试)。不足之处是它们只能按照预定义的模式机械测试,大多数情况下无法真实反应实际应用环境的IO模式。
2.
直接在真实的应用环境中进行性能测试。这种方法测出来的结果,针对特定的场景,具有权威的参考性。不足之处就是搭建环境可能比较麻烦,每个应用的依赖环境都不一样。即使是同样的存储设备,在不同的应用场景,其性能差异也很大。所以这种方法能反应存储产品在特定场景下的实际性能,但有时候并不能确定存储产品的普遍性能。
使用同样的存储设备,同样的硬盘,当如下条件变化时,性能差异可能会很明显。
【存储性能测试漫谈】1.
读和写。理论上,机械硬盘的顺序读写性能差不多。但在不同的场景,同样硬盘的读写性能是有差异的。因为写数据的时候,缓存的作用更大,所以写的性能可能更好。但如果使用RAID5,因为写数据有写惩罚,所以在其他条件相同时,读的话性能更好。SSD的读写参数天生就不一样,因为写数据会引起块擦除,所以往往读更快,尤其是随机读。
2.
顺序IO和随机IO。对于机械硬盘,毫无疑问,顺序读写比随机读写快很多,因为顺序读写少了很多寻道时间,其速度比随机读写高出1到2个数量级。所以,传统的存储需要使用缓存算法(包括按扇区地址的排序以及预读等)来减少寻道时间,提高性能。对于SSD,顺序读写和随机读写差别不是那么大,但是顺序读写一般来说会比随机读写快。实际应用中,纯随机读写很少,即使在文件系统中拷贝大文件,也有一些相对随机的操作,比如修改元数据,跳过一些被占用的扇区等。所以,如何模拟应用程序的随机度,是一个比较头疼的问题。
3. 块大小(block
size)。如果单次IO写入的数据块比较大,比如超过了1MB,性能显然比较好。即使是机械硬盘纯随机写入1MB也如此——单个数据块往往是一次性提交给驱动的,每个块内部的数据一般也是连续的。每秒只需要少量的IO能过去,就能获得较大的带宽,因为带宽=IO大小*IO数,IO数虽然不多,但IO平均大小较大。但也有例外。如果把块大小设置成很大(比如1GB),在系统里面肯定会被拆分成较小的IO发下去,所以性能不会有进一步改善,在应用程序不够完善时反而会导致额外的问题(比如直接就给分配了1GB的内存导致内存有可能不足)。即使前面说的1MB的IO,在很多系统中,也可能会被拆分成2个或者几个IO发下去。如果是顺序读写,4KB的小IO,在操作系统内部也可能会被合并成大的IO,所以这种情况下,性能不会太差,但合并IO等步骤本身需要消耗资源,所以性能也不会太好。需要注意的是,有些时候,评判性能标准不是按读写带宽来看,而是按照每秒的IO数(IOPS)来看。显然,块大小的设置就比较难提高IOPS的值了。
4.
缓存的影响。当读写缓存比较大时,性能显然会好一些。尤其是进行随机写测试,在写缓存比较大时,刚开始的性能值会非常大(其实就是写到内存的速度),到后来一下子降下来。因此,为了避开缓存的的影响,有时候需要测试direct
IO。但在大多数应用场景下,缓存都是需要使用的,我们得了解在缓存起作用的情况下的性能,同时又要跳开刚开始测试阶段的不稳定性能值,那我们可以设置相应的时间参数,不把最开始的一段时间的性能值统计进去。IOMeter的Ramp
Up Time就是为这个准备的。有人拿同样的配置测试随机读写,两次测出的值大不一样,其原因就有可能是没有把这个原因考虑进去。即使设置了Ramp Up
Time,但其值太小,在缓存还没有写满的时候其时间就到了,也会统计得不准确。
5.
同步IO和异步IO。同步IO是发一个IO,等确认完成之后,再发下一个IO。这是一个串行的过程。异步IO是发了一个IO,还没有完成,就发下一个IO,IO的处理过程是异步的。显然,异步IO的性能一般会好一些。IOMeter和fio等都能对它们进行测试。IOMeter有一个“#
of Outstanding I/Os”的参数,用于设置可以同时发的异步IO的个数。如果要测试出比较好的性能,一般要用异步IO。
6.
其他影响因子。太多了,无法一一列举。比如多线程、机械硬盘的外圈和内圈等。现在的机械硬盘内部结构很复杂,扇区的物理排布和硬盘的固件有关,但一般可以简单认为,机械硬盘的开始部分(扇区地址较小部分,或者简单认为是外圈)比结尾部分(扇区地址较大部分,或者简单认为是内圈)的速度要快。
因为有如此多的影响性能的因素,所以,也需要测试工具要提供众多参数来进行设置,以便精准地测试性能的原因。但实际的应用场景可能更复杂,有可能一会儿是大块的顺序读写,一会儿又变得更随机。如果我们能够精准预估应用程序读写存储的模式,理论上也可以用IOMeter等工具来模拟,无非是把配置写得比较复杂而已。但有时候很难预估它的读写模式,所以采用实际的应用环境更具有性能参考意义。因为实际应用环境搭建麻烦,所以,有时候会自己写一些测试工具,尽可能模拟应用场景,然后以比较简单的模式来进行测试,可以有更高的测试效率,以便不断改进系统。如需了解更多测试技术信息请关注:深圳多测师软件与技术服务有限公司
推荐阅读
- linux下lvm逻辑卷配置
- Kubeadm集群证书过期后的处理
- C语言简单实现“猜数字小游戏”
- 递归和非递归(青蛙跳台阶讲解)
- lvm缩减和迁移快照删除等
- 如何为 .NET 项目自定义强制代码样式规则#yyds干货盘点#
- springboot html vue.js 前后分离代码示例
- 4种典型限流实践保障应用高可用|云效工程师指北
- OpenHarmony——ets自定义弹窗UI组件封装