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

–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队列.

（编辑：网站开发网_盐城站长网 ）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!