大神教你玩转 SSD 系列三：数据处理

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

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

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

四、数据处理

本篇主要介绍第四点——数据处理,在后面的文章推送中会继续将把本系列的其他各主题分享给大家.

如果记录原始log,日志都很大,好处是可以利用这些原始日志按照想要的粒度随意进行多次的拆分.

下面是之前测试记录的原始日志.

1. 2016/09/21  10:25    <DIR>          .
2. 2016/09/21  10:25    <DIR>          ..
3. 2016/09/19  01:30     1,027,468,938 log_read_fio_4k_qd16_bw.1.log
4. 2016/09/19  01:31       955,376,526 log_read_fio_4k_qd16_clat.1.log
5. 2016/09/19  01:32       864,600,350 log_read_fio_4k_qd16_iops.1.log
6. ......此处省略若干行......
7. 2016/09/19  12:43     2,890,345,859 log_write_fio_4k_qd8_bw.1.log
8. 2016/09/19  12:47     2,678,596,965 log_write_fio_4k_qd8_clat.1.log
9. 2016/09/19  12:49     2,432,692,073 log_write_fio_4k_qd8_iops.1.log
10. 2016/09/19  12:45     2,678,904,975 log_write_fio_4k_qd8_lat.1.log
11. 2016/09/19  12:46     2,510,603,551 log_write_fio_4k_qd8_slat.1.log
12.              60 File(s) 85,850,810,754 bytes
13.               2 Dir(s)  279,943,782,400 bytes free

解释一下其中的命名,前面的 logxxxfio_xxx基本都一样,是用户指定的前缀.
后面的 iops, clat, slat, lat, bw 等是对应的测试项.

bw 是带宽
clat slat 和 lat 是每次 io 操作的延迟.
其中 slat 是io请求提交到操作系统,得到响应的时间,经过分析发现这个时间一般都很短,可以忽略.
clat 是 io 操作完成所需要的时间,一般来说可以认为是 设备从接到 io请求到完成的时间. lat 就是整个时间了, so, clat + slat = lat. 但由于 slat 很小,看 lat 和 clat 区别不大.既然是做磁盘基准测试,瓶颈总不能在操作系统吧,因而后期的测试都指定了 disable clat 和 slat .

原始日志格式如下：

fio 带宽log

1. # fio bandwidth log
2. 0, 21005, 0, 4096
3. 0, 20378, 0, 4096
4. 0, 21222, 0, 4096
5. 0, 22755, 0, 4096

fio iops log

1. # fio iops log
2. 0, 1, 0, 4096
3. 0, 1, 0, 4096
4. 0, 1, 0, 4096
5. 0, 1, 0, 4096

fio 延迟 log

1. # fio s / c / latency log
2. 0, 453, 0, 4096
3. 0, 435, 0, 4096
4. 0, 436, 0, 4096
5. 0, 436, 0, 4096

格式比较好猜.除了那一排0,于是 google,有人问过了：http://www.spinics.net/lists/fio/msg01064.html

如果记录的原始值,剩下的问题就是套路了,按照需要的分度做一些简单的加和,最大值最小值运算统计：

log文件结构都很简单,很容易改成 csv,并保留原始数据.其中bw数据可能会让人感觉有点奇怪.搜到的解释：

Time: in milliseconds. Bandwidth logs are usually 500 or 1000ms apart;
that can be controlled by the config file with “bwavgtime=[x ms]”.
Rate/latency: for bandwidth, this is in KB/sec. For latency, it’s microseconds.

然而实际计算发现,bw 的数据并没有那么平均,而是每次完成io之后,block size / clat 的值. 既然fio都这么设计,那bw log实际上来看用处已经不大,因为有iops log + clat log,一样的. 于是作图中,也选用clat,忽略 lat和slat了,毕竟 slat 都很小(对于sata设备来说忽略不计),clat和lat基本就一样了.

文件大小也小了好多好多.其实如果指定了采样间隔,fio自身生成log也跟这个类似,实际测试可以考虑直接指定对应参数. 数据文件处理完毕,可以按照需求作图了,作图可以直观的看到趋势,更容易发现问题.

这是测试中的两款磁盘,都直接从稳定态开始进行的测试,由于持续读写测试没有太大意义,故不做介绍,以4K随机为例做一个对比
先上两张随机读取的对比图：

Read Latency SanDisk

Read Latency Micron

Read iops SanDisk

Read iops Micron

前两张图是读取延迟的对比图,可以看到读取延迟大家都没超过毫秒级,由于是企业级的盘,加上raid卡神秘加成,可以看到两个盘几乎都是一条直线下来.区别是 SanDisk的延迟明显比 Micron的延迟低.查过datasheet可以知道美光用了3D eTLC,相比传统MLC来说,TLC相对有较高的延迟并不奇怪.

同时可以看到 Micron的磁盘延迟上下浮动范围稍宽,iops也有类似的表现,对于SanDisk,则几乎是一条直线,也可以看出SanDisk的性能几乎保持在同一个水平,对请求的处理及时,到位.但Micron的这一点点波动,不会对服务产生可以感知的影响,只是经过作图,直观的感受.但如果测试结果发现,波动范围非常大,那就要小心了.它可能是线上服务质量的杀手.

服务质量的好与坏,主要看延迟有多高,如果最长的延迟非常高,那平均时间也好不到哪去,而且通常最大延迟高的盘,延迟超过容忍程度(比如 200 ms)的几率也相对更高,直观表现就是“一卡一卡的”.

取某个时间段内的最大值,如果绝大多数时间这个最大值接近理想的平均值,并且整个测试阶段的最长时间在可以接受的范围内,出现的频率也不是很高,那么势必平均延迟也不高,可以判定整体服务质量还不错.

其实随机读取对于各种SSD来说其实是小儿科.因为没有什么成本,主控不忙,闪存不忙.确切的说,跟写入比起来,轻松许多,极少 wear leveling,极少 GC,极少擦除

于是此处应有写入测试(其实是混合读写测试,读3写7).

random wr latenct SanDisk

random wr latenct Micron

random wr iops SanDisk

random wr iops Micron

于是看起来就比较费劲了.

SanDisk的磁盘之前在线上机器服役过几个月,Micron的是新盘.

可以看到SanDisk的测试结果离散度比较大,跟美光的“一条直线”比起来,一点都不养眼.但并不意味着磁盘性能不好.虽然延迟范围比较大,但最大延迟控制在了 2ms 以内,跟美光的盘差不多,并且可以看到不同QD下,延迟也有上限,iops没有出现零点,而对于2ms QD32 的延迟来说,业务无感知.

美光的几乎是新盘(但在测试过程中也早就达到了稳定态)表现相对养眼一点,但并不抢眼,因为对比可以看出,美光的盘平均写入延迟都比同QD下SanDisk的要高,而且写入吞吐量要比 SanDisk的略低一点(SanDisk 12K 左右,Micron大约10K),原因,同样是TLC和 MLC的差别,同时,SanDisk有200多G的 OP,而美光,只有40多G,美光说：这还是有些许的不公平啊.

由于盘都是在进入稳定态之后的测试结果,所以喜闻乐见的磁盘性能下降都没能在图上反映出来,如果是全新的盘,可以明显看到iops分层的现象,比如之前美光M4的结果：

而且图中还能看到iops的零点,同时最高延迟也飙到了 600ms,像这种服务质量,是无法保证线上服务质量的.当然,这也只是一块消费级的盘.

在完成了对两张磁盘的“虐待”之后,其实还有一点需要关心的,就是磁盘的写入放大.

写入放大一词,最早由Intel提出,随着 NAND 颗粒容量的增大,page 也从 4k 变成 8k, 16k,32k……,而且NAND擦除时,并不能直接擦除一个 page,加上磨损平衡策略,造成了实际写入 NAND 的数据量大于 主机写入的数据量.这种写入放大在 4k 随机写入测试时尤为明显.线上的 RDBMS 应用,KV 存储记录,分布式 block / object 存储,更多的用到了随机写入.因而能减小写入放大,就能在某种程度上延长SSD的使用寿命.

可能有些公司已经开始采用 PCI-E卡甚至 NVMe SSD用于线上业务,当然这是极好的,NVMe为SSD而生,硬件性能需要满足业务需求,但至少,SSD作为通用存储,要满足以下一个要求,才能保证一般线上业务(比如RDBMS)的稳定.

• 测试过程中读取 写入不能出现零点.
• 读取写入延迟在可以预见的范围内(一般高压不能超过5ms).
• 不能依靠 Trim 来维持SSD 的性能.

4k 无文件系统测试能否代表真实的磁盘性能

有些盘拿到手之后,跑上几十个小时的4k qd32 write,效果相当不错,iops,带宽,延迟都在比较理想的范围之内, 但是否能代表有文件系统时磁盘的性能?通常认为,差别不大.可能有文件系统的时候会稍稍慢一点.但网上有一哥们确实遇到了很诡异的事情 (http://www.vojcik.net/samsung-ssd-840-pro-performance-degradation/).

某品牌的磁盘在特定固件版本下,特定文件系统表现非常不稳定.如果没有做过全面测试,这种事情出现在线上,是非常崩溃的, 并且,排查问题几乎完全找不到头绪.

trim,raid卡造成的性能波动

虽然本次测试覆盖了一款 raid 卡,但实际生产环境中每一批的固件,缓存策略等均可能对性能和稳定性产生影响,因而有必要做兼容性测试

高压环境下的稳定性、极端环境、掉电,上电测试

短时间的压测或基准测试可能并不能将产品潜在的bug发掘出来,比如镁光有就有著名的 “5200小时门”,虽然是消费级产品,但已经足够毁灭一大批数据.又诸如Intel的祖传 “8M门”,国外也有DC S3700用户中奖.测试只是划定门槛的手段.

以上就是 SSD 系列的完结篇,如果想看之前的两个主题,戳这里：

《大神教你玩转 SSD 系列一：关注哪些指标》

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