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

–log_avg_msec 本次采用1000,即每秒,相对记录原始数据来说 fio 占用的内存会大大减少.巨大的原始数据log也会占用大量磁盘空间,如果并非一定要记录原始数据,建议开启.

2.1 全盘无文件系统

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

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

• • 顺序读取测试
  • 顺序写入测试
  • 顺序混读写混合测试
  • QD1,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一线技术杂谈

（编辑：ASP站长网）