大神教你玩转 SSD 系列二:基准测试环境和项目
《大神教你玩转 SSD 系列二:基准测试环境和项目》要点: 如何评估固态存储设备的性能,并根据业务需求挑选出合适的SSD产品?在上一篇中,介绍了 SSD 基准测试应该关注哪些指标,这里我们继续关注基准测试环境和具体测试项目. 前言本系列将分为以下 4 个主题进行介绍. 一、SSD基准测试应该关注哪些指标 二、基准测试环境(工具/磁盘要求等) 三、针对磁盘的具体测试项目 四、数据处理 本篇主要介绍第二、三点——基准测试环境和具体测试项目,在后面的文章推送中会继续将把本系列的其他各主题分享给大家. 基准测试环境1.1 测试环境
1.2 工具
测试工具选择有很多,比如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). 1.3 磁盘要求
已经踩过的坑:
1.4 脚本测试中没有使用 jobfile 的形式,而是直接使用了命令行,其实这两种没有什么本质区别,依据个人喜好.
介绍一下测试中可能会用到的参数 –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也会占用大量磁盘空间,如果并非一定要记录原始数据,建议开启. 应该关注的测试项目2.1 全盘无文件系统
2.2 全盘主要文件系统 (ext4,ext3,XFS等)
即便是只做全盘的测试,不考虑不同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一线技术杂谈 (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |