eBay PB 级日志系统的存储方案实践( 四 ) _日志系统

其中 [8K, 12K) 区域已经是个碎片，但因为和周边区块不是同样大小，落到不同的 bin 中，已经很难再被合并了，而类似的操作序列，在 Bluestore 日常面临的空间分配回收请求中并不鲜见。
OSD 重启过程中，分配器的内存结构会根据磁盘上的位图重新建立，恰好是一次全局的合并，这也就解释了为什么重启服务能暂时缓解这个问题。

文章插图

图 8（点击可查看大图）
我们首先在社区发现定位了这个问题，并与核心开发者一起验证了 Naultilus 中的位图分配器（Bitmap Allocator）没有类似问题，且性能表现更为稳定。因此也使得位图分配器被完整地反向移植到 Luminous 和 Mimic 版本中，并成为默认分配器。
2. 应对 SSD 稳态性能下降关于 SSD 性能有一个并不冷门的常识——SSD 的稳态性能与标称性能不一定是一致的。对于普通数据中心级别的 SSD 来说，稳态性能通常比非稳态性能低（相应的，非稳态可以认为 SSD 尚有足够空间供分配，或者后台维护行为对业务 IO 无干扰），非写入密集型的型号差距会尤其明显。
SSD 进入稳态是需要一定写入量和时间的，因此在做硬件性能和软件性能调优时需要将这个因素充分考虑进去，否则实际产品运行起来以后就会出现意料不到的问题。
图 9 是我们实测某 DWPD 为 0.7 的产品稳态与非稳态性能比较。蓝色线是稳态性能，橘色线是非稳态性能（对 SSD 做了全盘 TRIM) 。

文章插图

图 9 SSD 稳态与非稳态性能对比（点击可查看大图）
受限于成本以及当前可用服务器选择，我们所采用的 SSD 即属于非写入密集型（DWPD 较低），同机型同容量，来自 3 个不同厂商的 SSD 的 DWPD 分布在 0.7～1 之间。而 eBay 日志存储 Cache Tier 恰好是写入读取都很密集的类型。这下，我们似乎面临了巧妇难为无米之炊的困境。
基于我们对 SSD 实现原理的理解，非写入密集型 SSD（DWPD 指标低）稳态与非稳态性能差距大的主要原因之一是厂商针对这类 SSD 的产品设计上，出厂预留的 Over Provision 空间较小。
当合理的产品设计面临“不合理”的业务需求时，大写入压力持续一段时间以后，SSD 固件做空间整理和垃圾回收（GC）的效率会变低。应用端的表现是在持续的大负载写入下，GC 发生时延迟和吞吐都会受到很大的负面影响。
分析完这个可能原因后，在无法变更硬件的前提下，我们的解决办法是通过主动预留空间，来弥补厂商原有 OP 先天不足的“缺点”：在 SSD 被加入集群前，我们对全盘 TRIM 之后，分区时只使用 80% 的空间；留下 20% 被 TRIM 过的区域因为在固件 FTL 中标记为空闲，自然会在 GC 等操作的时候当作缓冲来使用。加上这额外的 20% OP 后，我们 SSD 的写入延迟和带宽都能稳定在最佳状态（图 9 中橘色线的性能）。
这套实践应用在同机型、多批次来自 3 个不同厂商的 SSD 上都获得同样好的效果，上线至今并未观察到衰减。
那么 20% 的空间预留是目前的经验值，当应用行为有所改变时 SSD 性能再次衰减又该怎么应对呢？需要停下服务重新修改预留空间大小吗？
其实不然，对于已经衰减的 SSD, 只需要 TRIM 20 的区域提供 OP，再经过一个完整的写入周期后，性能就可以回升到最佳状态。
图 10 展示的就是这样一个过程，在模拟测试开始约 600 秒时，性能开始大幅下降，此时对预留的 20% 区域做 TRIM，经过一个多小时，性能逐步回升，最终回到峰值并持续稳定下去。

文章插图

图 10 对预留区域 TRIM 恢复全盘性能测试（点击可查看大图）
在这里需要指出：上述经验是我们基于存储产品的理解和合理猜测基础上，经测试验证通过，并在生产中应用的。限于条件和知识所限，我们无法进一步探究 OP 是否是同系列不同定位的 SSD 产品之间的主要差别。
通过我们所接触的有限样本中的数据，可得出以下观点：读密集型 SSD 加上大的 OP，能达到同系列写入密集型 SSD 同样的性能和可靠性，但我们并不确定该经验是否在更大范围内具有通用性。这里仅供读者参考，也欢迎来自各厂商的专家提供更多的分享。