RocksDB 性能的银弹

Stefan Kooman (hydro-b)

没有针对RocksDB性能的灵丹妙药。现在我引起了你的注意：如果你使用的是上游Ceph Ubuntu软件包，你可能会“幸运”一些。

TL;DR

Mark Nelson 发现 在合并拉取请求（PR）之前，构建过程没有正确地将CMAKE_BUILD_TYPE选项传播到Ceph构建的外部项目——在本例中，RocksDB。 之前，软件包是使用RelWithDebInfo构建的，以构建“性能”发布软件包。虽然尚未验证，但从Luminous以来，上游Ceph Ubuntu软件包可能也受到此问题的影响。

致谢

感谢Mark Nelson发现并修复此问题。感谢Kefu Chai提供构建系统修复。感谢Casey Bodley负责创建回溯跟踪器。感谢我的雇主BIT让我参与Ceph工作，以及Els de Jong和Anthony D'Atri的编辑。

那么这意味着什么？

在没有RelWithDebInfo的情况下构建时，RocksDB性能不佳。可以通过安装“性能”软件包构建来缓解此问题。实际性能提升取决于集群，但RocksDB压缩减少了三倍。在某些情况下，随机4K写入性能翻倍。请参阅这些链接 1 和 2。

如何解决此性能问题？

  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

注意：如果您只需要二进制软件包而不需要源代码软件包，请将“-b”选项添加到dpkg-buildpackage。确保您有足够的可用文件空间和足够的内存，尤其是在使用大量线程构建时。我使用了一个具有256 GB RAM、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-linux-gnu/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='-Wno-deprecated-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 SSD的节点。带有NVMe磁盘的节点速度更快。压缩时间在3-5分钟之间。

调试软件包磁盘IOPS（之前）

性能软件包磁盘IOPS（之后）

请注意SATA SSD和NVMe驱动器之间的OSD压缩时间差异越来越大。以前，由于RocksDB的性能问题，这种差距并不那么大。但是，随着更快、更低延迟的磁盘的引入，这种差异变得更加明显。这表明，配备更快磁盘的集群可以观察到最显着的性能改进。

在这个特定的集群中，性能软件包将压缩所有OSD所需的时间减少了大约三分之一。以前需要九个半小时，现在完成时间为六小时。

实际性能提升

虽然我们希望看到性能翻倍，但这并没有发生。但是，我们仍然看到了一些显著的性能改进。为了检测灰色故障，我们有虚拟机在我们的云上运行，以持续（每5分钟间隔）监控从虚拟机内部体验到的性能。其中一项测试是FIO 4K随机写入测试（单线程，队列深度为1）。

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

CephFS上的4K随机写入（之后）

我们还执行了其他fio基准测试，主要好处是标准差较低，尾部延迟降低了。

结论

  • 正如Mark Nelson所做的那样，针对“已知良好”集群进行性能验证是值得的。这有助于及早发现性能问题，然后再运行生产工作负载。
  • 配备更快磁盘的集群比那些使用较低性能驱动器（如SAS/SATA SSD或HDD）的集群更有可能看到显著的性能改进。

建议/注意事项

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

好吧，在实践中这可能太过分了，但为了发现像这样的问题，最好进行一些不同的测试。

  • 随着时间的推移，进行这些测试可以导致更标准化的指标，例如“IO/瓦特”或“吞吐量/瓦特”比率，这将允许更轻松地比较不同的测试。也许我们可以开发Ceph特定的测试，用于Phoronix测试套件？

  • 虽然在本例中不是问题，但值得注意的是，与特定CPU架构相关的性能回归可能存在。例如，同时拥有ARM64和x86-64性能集群可以揭示与特定构建选项相关的差异。这种方法有助于及早发现这些回归。

感谢您的阅读，如果您有任何问题或想进一步讨论Ceph，请随时联系。