《大神教你玩转 SSD 系列二:基准测试环境和项目》要点:
本文介绍了大神教你玩转 SSD 系列二:基准测试环境和项目,希望对您有用。如果有疑问,可以联系我们。
如何评估固态存储设备的性能,并根据业务需求挑选出合适的SSD产品?在上一篇中,介绍了 SSD 基准测试应该关注哪些指标,这里我们继续关注基准测试环境和具体测试项目.
本系列将分为以下 4 个主题进行介绍.
一、SSD基准测试应该关注哪些指标
二、基准测试环境(工具/磁盘要求等)
三、针对磁盘的具体测试项目
四、数据处理
本篇主要介绍第二、三点——基准测试环境和具体测试项目,在后面的文章推送中会继续将把本系列的其他各主题分享给大家.
测试工具选择有很多,比如fio, iometer, iozone, sysbench 等,但之所以选 fio,有以下原因:
fio 可以使用一系列的进程或者线程,来完成用户指定的一系列io操作,典型的使用方式是写一个 JobFile,来模拟特定的 io 压力.
fio是测试IOPS的非常好的工具,用来对硬件进行压力测试和验证,支持13种不同的I/O引擎,包括:sync,mmap, libaio, posixaio, SG v3, splice, null, network, syslet, guasi, solarisaio 等等.
对于单qd,可以直接用 sync,对于多qd,libaio + 深qd 或者 深qd+多进程(numjobs).
已经踩过的坑:
测试中没有使用 jobfile 的形式,而是直接使用了命令行,其实这两种没有什么本质区别,依据个人喜好.
/usr/local/bin/fio –filename={FIO_TEST_FILE}
–direct=1
–ioengine=libaio
–group_reporting
–lockmem=512M
–time_based
–userspace_reap
–randrepeat=0
–norandommap
–refill_buffers
–rw=randrw –ramp_time=10
–log_avg_msec={LOG_AVG_MSEC}
–name={TEST_SUBJECT}
–write_lat_log={TEST_SUBJECT}
–write_iops_log={TEST_SUBJECT}
–disable_lat=1
–disable_slat=1
–bs=4k
–size={TEST_FILE_SIZE}
–runtime={RUN_TIME}
–rwmixread={READ_PERCENTAGE}
–iodepth={QUEUE_DEPTH}
–numjobs={JOB_NUMS}
介绍一下测试中可能会用到的参数
–filename 指定fio的测试文件路径.可以是文件或设备(设备需要root权限)
–direct=1 绕过缓存
–ioengine=libaio 使用libaio,linux原生异步io引擎,更多引擎参考fio man
–group_reporting 将所有的进程汇总,而不是对于每一个job 单独给出测试结果
–lockmem=512M 将内存限制在 512M,然而实际测试中发现似乎没什么用,有待考察
–time_based 即使文件读写完毕依旧继续进行测试,直到指定的时间结束
–rwmixread 读写比例,0为全读,100为全写,中间为混合读写
–userspace_reap 提高异步IO收割的速度.
这是霸爷的解释 ( http://blog.yufeng.info/archives/2104 ),未做深入研究,但从测试来看,似乎影响不大
–randrepeat=0 指定每次运行产生的随即数据不可重复
官方解释 Seed the random number generator in a predictable way so results are repeatable across runs. Default: true.
–norandommap 不覆盖所有的 block
一般来说,在进行4k 读写时,由于随机数的不确定性,可能有些块自始至终都没有被写到,有些块却被写了好多次.但对于测试来说 是否完全覆盖到文件并没有什么关系,而且测试时间相对足够长的时候,这些统计都可以略过.
–ramp_time=xxx(seconds)
指定在 xxx 秒之后开始进行日志记录和统计(预热),非稳态测试这里指定了10秒,用于让主控和颗粒“进入状态”
–name 指定测试的名称,代号
–write_latency_log=latency_log前缀 记录延迟日志
–write_bw_log 记录带宽(吞吐量)日志
–write_iops_log 记录 iops 日志
–bs=4k 4K测试
–size=XXXG 指定测试文件大小,如不指定,写满为止 或者全盘(例如/dev/sdX /dev/memdiskX)
–runtime=1200 执行1200秒,或者执行完整个测试,以先达到的为准.如果指定了 –time_based,则以此为准.
–log_avg_msec 本次采用1000,即每秒,相对记录原始数据来说 fio 占用的内存会大大减少.巨大的原始数据log也会占用大量磁盘空间,如果并非一定要记录原始数据,建议开启.
即便是只做全盘的测试,不考虑不同OP的情况,也已经有十几项,根据磁盘大小的不同,一项的测试时间也从两小时~几十小时不等.如果所有的测试都进行,从开始测试到收割数据将是一个相当漫长的等待.并且这种测试还不能够并行执行.因而,选几个典型的,线上可能出现的测试就可以.
本次进行了QD1-32的读取,写入,混合读写测试.
测试应该控制在多少时间,可以粗略的估算:比如某一款磁盘宣称的最大 iops 为 100,000 iops,换算成带宽,100000 * 4K 为越 400M,要超过至少写满3次磁盘容量,让磁盘变得足够脏的时间.
测试脚本为通用脚本,其中{}内的数据会根据测试项目动态生成,一共十多个项目,每个项目对应一个脚本.
由于机器性能尚可,当 queue depth 达到32的时候,磁盘性能已被榨干,但单核心cpu占用率远没有到 100%(实测平均在 40%左右,峰值60%左右),可以认为处理器性能不是基准测试的瓶颈. 但对于一些性能彪悍的 NVMe 设备或 PCI-E 卡,在队列深度达到64的时候,磁盘性能还没有被榨干,但单个CPU核心已经100%了,此时需要保持 QD 在一个相对低一些的水平,增加 numjobs,使得总qd上去.来保证磁盘被“喂饱”,以免测试结果不准确.但目前来看,一般业务真的很难用到QD64队列.
于是此处又要注意几个问题:
以上就是在做基准测试时选择的测试环境以及具体的测试项目,下一篇将会介绍测试数据处理.
可以从上一次推送《大神教你玩转 SSD 系列一:关注哪些指标》了解最关注 SSD 的哪些指标.
原文来自微信公众号: HULK一线技术杂谈
转载请注明本页网址:
http://www.vephp.com/jiaocheng/4213.html