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

为促进社区发展,运维派寻求战略合作、赞助、投资,请联系微信:helloywp

SSD固态硬盘

如何评估固态存储设备的性能,并根据业务需求挑选出合适的SSD产品?在之前两篇文中,介绍了 SSD 基准测试应该关注哪些指标以及测试环境,今天我们把最后一个主题也分享给大家——数据处理。

前言

本系列将分为以下 4 个主题进行介绍。

一、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 系列二:基准测试环境和项目》

网友评论comments

发表评论

电子邮件地址不会被公开。 必填项已用*标注

暂无评论

Copyright © 2012-2019 YUNWEIPAI.COM - 运维派 - 粤ICP备14090526号-3
扫二维码
扫二维码
返回顶部