大神教你玩转 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 系列二：基准测试环境和项目》