Ceph 社区最近冻结了即将发布的 Ceph Reef 版本，今天我们研究一下 Ceph Reef 版本在 10 个节点、60 个 NVMe 磁盘的集群上的 RBD 性能。

在确保硬件没有问题（NVMe 固件更新）后，Reef 能够保证约71GB/s的性能读取和25GB/s的性能写入（75GB/s 复制速度）。

对于小型随机 IO，Reef 提供了大约4.4M 随机读取 IOPS和800K 随机写入 IOPS（2.4M 复制速度）。

对于小型 4K 顺序同步写入，Reef 实现了低于 0.5 毫秒的平均延迟、低于 0.5 毫秒的 99% 延迟和低于 0.8 毫秒的 99.9% 延迟。

即使在商业硬件设备上执行 3 倍的同步复制，它也实现了低于 8 毫秒的最大延迟。

虽然 Reef 要比 Quincy 性能更佳，但我们也发现了一些小问题。

在 Reef 冻结期间，我们将研究这些问题，以帮助 Reef 成为迄今为止最好的 Ceph 版本。

每个版本对我们来说最重要的测试是小型随机 IO 测试。

这些测试通过对 OSD 增加压力，从而确认 IO 的效率。

在这种情况下，我们总体上得到了相对较好的结果，但有几点需要注意。

在 4K 随机读取方面，Reef 仅比 Quincy 慢一点点，但非常接近。

另一方面，我们看到 4K 随机写入测试有了一定的改进，这主要是由于引入了新的 RocksDB 调优。

不过，根据去年秋天的结果，我们并没有看到像预期那样大的性能提升。在随机读取测试中，每个 OSD 的 CPU 使用率略高于 7 个内核，而在随机写入测试中，Reef 的每个 OSD 将近 11 个内核。这似乎与 Quincy 的更高性能成正比。

在测试 Ceph 的小的随机写入性能的时，加入拥有无限 CPU 资源，那么 kv_sync_thread 则会成为瓶颈，但 CPU 的消耗主要发生在 OSD 工作线程和信使线程中，因 CPU 造成的性能瓶颈场景还是比较少的。

因此，最大化写入性能是 OSD 数量、NVMe 速度、核心数量和核心速度之间的微妙平衡。

Reef 中的随机写入性能高于 Quincy，但没有我们希望的那么高。这是为什么？

还有两个额外的测试可能会提供一下原因。

就在我们冻结 Reef 之前，我们升级到最新版本的 RocksDB，因为与我们在 Quincy 中使用的旧版本相比有几个重大错误修复和改进。

我们可以简单地还原该更改，然后看看 Reef 的表现如何。

我们还可以使用我们现在在 Reef 中作为标准使用的 RocksDB 调优来运行 Quincy，看看它能在多大程度上提高 Quincy 性能。

使用 Reef 调整在 v17.2.5 上运行特别慢之外，但非常接近。

当使用旧的 Quincy 版本的 RocksDB 编译 Reef 时，似乎确实有一致的性能提升，尽管很小（~2%）。

使用相同版本的 RocksDB 编译的 Quincy 和 Reef 则保持一致。

在随机写入场景中，我们看到两个非常有趣的结果。

一：当 Quincy 使用新的 RocksDB 调整默认值编译时，无论它使用哪个版本的 RocksDB，它实际上都比 Reef 快。

二：恢复到旧版本的 RocksDB 确实会带来性能提升，但同样非常小（~1-2%）。它不能完全解释当 Quincy 和 Reef 都使用新的 RocksDB 调优时出现的回归。

最终结果是 Reef 中很可能会出现小的回归，从而影响小的随机写入。

    推荐阅读   

    推荐视频