关于Ceph的RocksDB的性能优化，并没有什么特别好的方式。但本文会给出⼀个比较好的改进方式:如果你使用的是上游 Ceph Ubuntu 软件包，那么改进会变的更简单些。

简单说明

Mark Nelson 发现，在合并Pull request (PR) 之前，构建过程没有正确地将CMAKE_BUILD_TYPE选项 传递给由Ceph构建的外部项目（在本例中为 RocksDB）。

此之前，软件包使用RelWithDebInfo构建，以构建 “performance”发布包。虽然尚未得到验证，但自Luminous 发布以来，上游Ceph Ubuntu软件包有可能都受到了影响。在不使用RelWithDebInfo的情况下，RocksDB的性能达不到最佳。

这可以通过安装 “peformance “软 件包来缓解。实际的性能提升取决于集群，但 RocksDB 压缩会降低 3 倍。在某些情况下，随机4K写入性能会提高一倍。

参见链接 ：

https://bugs.gentoo.org/733316

https://ceph.io/en/news/blog/202 4/ceph-a-journey-to-1tibps/

该如何解决这个性能问题？

1. 对于您正在运行的版本，安装已解决此问题的版本：Pacific、Quincy、Reef。
2. 如果您正在运行Ceph 的 EOL 版本，您可以自己构建它。请参阅文档或下面的简短版本。

git clone [ceph](https://github.com/ceph/ceph.git)
cd ceph
git checkout vYour_Release_Verion
add "extraopts += -DCMAKE_BUILD_TYPE=RelWithDebInfo" to debian/rules file
./do_cmake.sh -DCMAKE_BUILD_TYPE=RelWithDebInfo
dpkg-buildpackage -us -uc -j$DOUBLE_NUMBER_OF_CORES_BUILD_HOST 2>&1 | tee
../dpkg-buildpackage.log

注意：如果只需要二进制包而不需要源代码包，请在dpkg-buildpackage 中添加”-b “选项。确保有足够的可用文件空间和内存，尤其是在使用大量线程构建时。我使用的虚拟机有 256 GB 内存、64 个内核 和 300 GB 空间，耗时约1小时7分（完整构建包括源代码包）。

请确保查看dpkg-buildpackage.log

并检查

DCMAKE_BUILD_TYPE=RelWithDebInfo

如下所示：

cd /home/stefan/ceph/obj-x86_64-linux-gnu/src/rocksdb && /usr/bin/cmake -
DCMAKE_POSITION_INDEPENDENT_CODE=ON -DWITH_GFLAGS=OFF -DCMAKE_PREFIX_PATH= -
DCMAKE_CXX_COMPILER=/usr/bin/c++ -DWITH_SNAPPY=TRUE -DWITH_LZ4=TRUE -
Dlz4_INCLUDE_DIRS=/usr/include -Dlz4_LIBRARIES=/usr/lib/x86_64-linuxgnu/liblz4.so -DWITH_ZLIB=TRUE -DPORTABLE=ON -DCMAKE_AR=/usr/bin/ar -
DCMAKE_BUILD_TYPE=RelWithDebInfo -DFAIL_ON_WARNINGS=OFF -DUSE_RTTI=1 "-GUnix
Makefiles" -DCMAKE_C_FLAGS=-Wno-stringop-truncation "-DCMAKE_CXX_FLAGS='-Wnodeprecated-copy -Wno-pessimizing-move'" "-GUnix Makefiles"
/home/stefan/ceph/src/rocksdb

验证实际 RocksDB 性能改进

我们在存储节点上安装了重建的软件包（其中 ceph-osd 是最重要的），结果是惊人的好。

并放大某个特定的 OSD

如果您发现自己需要压缩 OSD，那么您将会感到惊喜。压缩 OSD 带来三大好处：

1. 提高了 RocksDB 本身的性能。

2. 增强的 OSD 写入性能，从而缩短恢复时间。

3. 减少停机时间，从而减少需要恢复的数据量。

服务器指标中的一些图可以说明这一点。我们压缩 OSD 的程序包括交错关闭 OSD。一旦所有 OSD 关 闭，就会并行执行压缩 (df|grep “/var/lib/ceph/osd” |awk ‘{print $6}’ |cut -d ‘-‘ -f 2|sort -n|xargs -n 1 -P 10 -I OSD ceph-kvstore-tool bluestore-kv /var/lib/ceph/osd/ceph-OSD compact )。

磁盘IOPS（优化之前）

磁盘IOPS（优化之后）

这是一个使用SATA 固态硬盘的节点。使用NVMe磁盘的节点速度更快。压缩时间为3-5分钟。磁盘IOPS（优化之前）

磁盘IOPS（优化之后）

请注意，SATA固态硬盘和NVMe硬盘在OSD压缩时间上的差距越来越大。以前，由于RocksDB 的性能问题，这种差距并不明显。但是，随着速度更快、延迟更低的磁盘的推出，这种差距变得越来越明 显。这表明，在配备更快磁盘的集群中，可以看到最显著的性能提升。

在这个特定的集群中，安装优化包后将压缩所有 OSD 所需的时间缩短了约三分之一。以前需要 9 个半小时，现在只需 6 个小时即可完成。

真实环境中的性能提升

虽然我们希望看到性能翻倍，但事实并非如此。不过，我们仍然看到性能有了显著提高。为了检测⼀些故障，我们在云上运行了虚拟机，以持续（每 5 分钟一次）监控虚拟机内部的性能。其中一项测试是FIO 4K 随机写入测试（单线程，队列深度为1）。

CephFS上的4K随机写入（优化之前）

CephFS 上的 4K 随机写⼊（优化之后）

我们还进行了其他fio基准测试，主要优点是标准偏差降低，尾部延迟也减少了。

结论

• 像 Mark Nelson 所做的那样，针对 “已知良好 “集群进行性能验证是有好处的。这有助于在运行生产工作负载之前及早发现性能问题。
• 与使用SAS/SATA SSD或HDD等低性能驱动器的集群相比，配备更快磁盘的集群更有可能实现显著的性能提升。

建议/注意事项

• 在进行性能测试时，探索各种部署策略。这可能包括在使用不同操作系统的裸机、使用上游容器的 容器化环境以及 Ceph 项目内支持的其他部署方法上进行测试。

在进行性能测试时，探索各种部署策略。这可能包括在使用不同操作系统的裸机、使用上游容器的 容器化环境以及Ceph项目内支持的其他部署方法上进行测试。

• 随着时间的推移，进行这些测试可以产生更标准化的指标，如 “IO/Watt “或 “throughput/Watt “比率，从而更容易比较不同的测试。或许我们可以开发针对Ceph的测试，以便与Phoronix 测试套件等工具配合使用？
• 尽管在这种特殊情况下不是问题，但值得⼀提的是，可能会出现与特定CPU架构相关的性能下降。例如，同时使用ARM64和x86-64 性能集群可以发现与特定构建选项相关的差异。这种⽅法有助于 及早发现此类问题。

  如有相关问题，请在文章后面给小编留言，小编安排作者第一时间和您联系，为您答疑解惑。