大神教你玩转 SSD 系列二：基准测试环境和项目

《大神教你玩转 SSD 系列二：基准测试环境和项目》要点：
本文介绍了大神教你玩转 SSD 系列二：基准测试环境和项目，希望对您有用。如果有疑问，可以联系我们。

如何评估固态存储设备的性能,并根据业务需求挑选出合适的SSD产品?在上一篇中,介绍了 SSD 基准测试应该关注哪些指标,这里我们继续关注基准测试环境和具体测试项目.

前言

本系列将分为以下 4 个主题进行介绍.

一、SSD基准测试应该关注哪些指标

二、基准测试环境(工具/磁盘要求等)

三、针对磁盘的具体测试项目

四、数据处理

本篇主要介绍第二、三点——基准测试环境和具体测试项目,在后面的文章推送中会继续将把本系列的其他各主题分享给大家.

基准测试环境

1.1 测试环境

• SanDisk CloudSpeed 800G * 4 RAID 5
• Micron 5100 ECO 960G * 4 RAID 5
• E5 2630 V2 *1
• 96GB DDR3 ECC

1.2 工具

• fio – 跨平台的 io 压力生成工具.功能强大,支持众多引擎和系统调优参数,数据采集,自带gnuplot画图脚本.
• iometer – io 压力生成器,带GUI界面,数据采集功能强大,功能和参数并不如 fio 多,多用于 Windows 平台(本次未采用).
• hdparm – linux下的磁盘工具,可以查看磁盘信息,用来进行安全擦除,设置 ATA 参数,设置HPA等
• smartctl – linux下查看smart信息的工具.
• python, perl, php, go, shell, awk, c, cxx …… 随便一个语言都行,用于处理fio生成的大量数据.
• excel – 没错,就是excel,用来处理数据作图.当然只是为了便于展示,实际自动化测试流程可以用任何语言直接处理数据生成图表.

测试工具选择有很多,比如fio, iometer, iozone, sysbench 等,但之所以选 fio,有以下原因：

1. 虽然上述工具基本都能胜任,但fio在linux下应用比较多,有比较深厚的群众基础, 文档和邮件组也相对完善,尤其是邮件组,好多遇到的问题都搜到了作者的回复,让我甚是感动.
2. fio更“专业”一些,iometer 相对可选择的参数少许多,应用平台也以windows为主,iozone 粗略看了一下,功能差不多,但国内用的较少,限于时间和经历没有深入研究
3. sysbench更适合一些特定场景的测试,比如OLTP,基准测试 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 磁盘要求

• 新盘或者做过完整的安全擦除
• 对于曾经设置过 HPA (Host protected Area, ATA8-ACS SET MAX ADDRESS),清除HPA
• 不应该使用raid,除非想测试raid下的性能 但其实这些都不是硬性要求.首先磁盘用用就变成脏盘了,第二,很少有人设置HPA,第三,多数SATA磁盘最终都会挂在RAID卡上用.所以以上三点都是测试单个盘的要求,最终,还是建议怎么用就怎么测.

已经踩过的坑：

• fio 版本不要使用 2.0.13,一开始直接通过包管理安装了 fio 2.0.13,使用中各种 CPU 100%, 数据飙高,还出了 core,于是被迫 cmm 大法编译安装了新版.
• 安装新版 fio 可能需要安装 zlib-dev libaio-dev,如果你在没安装前就编译了,需要重新编译.

1.4 脚本

测试中没有使用 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也会占用大量磁盘空间,如果并非一定要记录原始数据,建议开启.

应该关注的测试项目

2.1 全盘无文件系统

• • 顺序读取测试
  • 顺序写入测试
  • 顺序混读写混合测试
  • QD1,QD2,QD4…QD32
    • 512B,4K,8K,16K 随机读取测试
    • 512B,4K,8K,16K 随机写入测试
    • 512B,4K,8K,16K 随机读写混合测试 (50/50)
    • 512B,4K,8K,16K 随机读写混合测试 (30/70)
    • 512B,4K,8K,16K 随即读写混合测试 (70/30)
    • 512B ~ 256K 随机读写混合测试
  • 写入放大测试

2.2 全盘主要文件系统 (ext4,ext3,XFS等)

• • 顺序读取测试
  • 顺序写入测试
  • 顺序混读写混合测试
  • QD1,QD2,QD4…QD32
    • 512B,4K,8K,16K 随机读取测试
    • 512B,4K,8K,16K 随机写入测试
    • 512B,4K,8K,16K 随机读写混合测试 (50/50)
    • 512B,4K,8K,16K 随机读写混合测试 (30/70)
    • 512B,4K,8K,16K 随即读写混合测试 (70/30)
    • 512B ~ 256K 随机读写混合测试
  • 写入放大测试7% OP (128G NAND 对应 119.3G 可用空间,常见的 128G 磁盘)
    13% OP (128G NAND 对应 111.7G 可用空间,常见的 120G 磁盘)
    27% OP (128G NAND 对应 93.1G 可用空间,常见的 100G 磁盘)条件下上述测试(非必选项)

即便是只做全盘的测试,不考虑不同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队列.

于是此处又要注意几个问题：

1. 记录日志的路径不要跟被测试的SSD在一起.比如 SSD挂在 /opt 进行测试,在shell里,当前工作目录或记录日志的目录就不要是 /opt,以免记录日志的时候影响到SSD.
   虽然测试过程中发现 fio 并不会边测试边写日志,而是在测试完成之后统一进行日志的记录.但在测试完成后,如果因为磁盘空间不够记录不下完整的日志,也是比较悲剧的事情.
2. 如果要记录原始日志,内存一定要大.或者你有性能够好的 swap(比如另一块 PCI-E卡或者 ssd,至少不能是机械盘那种不能容忍的慢,因为fio在进行日志收集的时候,会写入大量的数据,占用一定的时间.这个时间对于一些高端企业级SSD足以恢复一部分性能,如果进行连续测试,可能结果会有些差异).
3. 如果测试记录原始日志,除非内存足够大,否则不要指定run_time 过长,最好几个小时就断一次,留出足够的时间和空间给 fio 写日志,把测试分成相对小的几个测试脚本,最后人工合并log做分析.原因同样是fio产生的巨大log.
4. 如果日志比较大,放弃自带的图像生成脚本吧,内存占用是一方面,生成的图像能不能打的开还是个未知数.

以上就是在做基准测试时选择的测试环境以及具体的测试项目,下一篇将会介绍测试数据处理.

可以从上一次推送《大神教你玩转 SSD 系列一：关注哪些指标》了解最关注 SSD 的哪些指标.

原文来自微信公众号： HULK一线技术杂谈

转载请注明本页网址：
http://www.vephp.com/jiaocheng/4213.html