如何评估固态存储设备的性能，并根据业务需求挑选出合适的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，有以下原因：
- 虽然上述工具基本都能胜任，但fio在linux下应用比较多，有比较深厚的群众基础， 文档和邮件组也相对完善，尤其是邮件组，好多遇到的问题都搜到了作者的回复，让我甚是感动。
- fio更“专业”一些，iometer 相对可选择的参数少许多，应用平台也以windows为主，iozone 粗略看了一下，功能差不多，但国内用的较少，限于时间和经历没有深入研究
- 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队列。
于是此处又要注意几个问题：
- 记录日志的路径不要跟被测试的SSD在一起。比如 SSD挂在 /opt 进行测试，在shell里，当前工作目录或记录日志的目录就不要是 /opt，以免记录日志的时候影响到SSD。
虽然测试过程中发现 fio 并不会边测试边写日志，而是在测试完成之后统一进行日志的记录。但在测试完成后，如果因为磁盘空间不够记录不下完整的日志，也是比较悲剧的事情。 - 如果要记录原始日志，内存一定要大。或者你有性能够好的 swap（比如另一块 PCI-E卡或者 ssd，至少不能是机械盘那种不能容忍的慢，因为fio在进行日志收集的时候，会写入大量的数据，占用一定的时间。这个时间对于一些高端企业级SSD足以恢复一部分性能，如果进行连续测试，可能结果会有些差异）。
- 如果测试记录原始日志，除非内存足够大，否则不要指定run_time 过长，最好几个小时就断一次，留出足够的时间和空间给 fio 写日志，把测试分成相对小的几个测试脚本，最后人工合并log做分析。原因同样是fio产生的巨大log。
- 如果日志比较大，放弃自带的图像生成脚本吧，内存占用是一方面，生成的图像能不能打的开还是个未知数。
以上就是在做基准测试时选择的测试环境以及具体的测试项目，下一篇将会介绍测试数据处理。
可以从上一次推送《大神教你玩转 SSD 系列一：关注哪些指标》了解最关注 SSD 的哪些指标。
原文来自微信公众号： HULK一线技术杂谈
本文链接：https://www.yunweipai.com/14941.html
网友评论comments