如何使用 RethinkDB 耗尽机器的资源？

Question

我问这个问题是因为我想了解如何更好地运行 RethinkDB，这意味着它应该在什么样的硬件上运行，应该在什么样的文件系统上运行，以及其他系统配置来最大化它的吞吐量。

我正在尝试尽可能快地用{"n": <counter>, "rand": <Math.random()>}. 我在某处读到这对于 200 个文档的批处理速度更快，所以这就是我要插入的内容。我也在使用柔软的耐用性。我开始了一个 nodejs 进程，我可以平均每秒插入 10k 个文档，非常好。

但是在发生这种情况时，rethinkdb 使用了大约 70% 的一个核心（我有 8 个虚拟核心，它是 i7-4770），而 nodejs 进程使用了​​ 5%。所以看起来CPU不是瓶颈。

一旦我开始另一个 nodejs 进程做同样的事情，两个进程上的每秒插入次数就会下降到大约 4k-5k。同样，CPU 负载保持不变。

我解雇了iotop，我确实在那里看到了很多行动，但不是我所期望的。我在 RAID0 中配置了两个 SSD，快速dd测试表明我可以以大约 800MBps 的速度写入和读取。这远高于 iotop 报告的实际读取和实际写入速度（平均读取 ~14MBps 平均写入 ~50MBps）。

那么我怎样才能耗尽我机器的资源呢？rethinkdb 需要什么才能运行得更快？为什么它不花费更多的资源并具有更高的吞吐量？

关于它运行的更多信息：它是Hetzner 的 EX40SSD，软件 RAID0 中的两个 SSD，ext4 文件系统（明天我将尝试安装它，noatime看看它是否更好）。默认情况下，rethinkdb 配置就是一切，插入是对只有一个分片和一个副本的表进行的。请随时询问我可能忘记提及的任何其他相关问题。

提前致谢。

Answer 1

我怀疑这里发生的是实际 btree 上的锁争用。当您插入大量文档时，系统会并行抓取 btree 的各个部分，以使用新文档对其进行更新。这是一组读写锁——系统的其他部分仍然可以读取，但是如果你并行插入另一个大batch，很有可能会碰到btree的相似部分，因此必须等待以便系统在插入第一批零件时开始解锁。（这不是 RethinkDB 特有的，而是一般数据库中的问题）这可能是您没有达到 100% CPU/磁盘吞吐量的原因。

您可以尝试一些方法，但请注意，各种方法都有其微妙之处。总体而言，基准测试很难。

• 您可以尝试将表分成 32 个分片，然后重试您的基准测试。您实际上不必创建集群，您可以在一台机器上分片成 32 个分片。这将导致多个 btree，因此您将最大程度地减少争用并能够使用更多的系统资源。请注意，虽然这可能会增加吞吐量，但增加分片数量也会略微增加延迟，因此在开始看到吞吐量增加之前，您可能需要显着增加并行度。
• 您可以尝试不批量写入，而是一次写入一个文档（这通常更接近实际用例）。然后，启动数百个并行客户端，而不仅仅是一两个，并让它们一次并行编写一个文档。请注意，在这种情况下，您需要确保客户端本身不是瓶颈。
• 您可以尝试重新运行您的基准测试，并同时启动从数据库中读取与写入并行的客户端。在 RethinkDB 中，即使您正在写入特定文档，读取通常也可以通过，因此这将使您有机会提高 CPU 使用率并绕过争用。
• 注意文件的ID。如果数据库足够大（例如，数百万个文档），并且您插入的 ID 是随机的，则您不太可能触及 btree 的相同部分，因此争用问题就变得不那么严重了。
• 您可以结合各种方法（分片、读 + 写、各种并发客户端数量）来开始了解数据库在各种场景中的行为。
• 请注意，可能会发生一些您通常不会意识到的事情。例如，RethinkDB 有一个日志结构的存储引擎，可以在磁盘上进行实时压缩，这可能会消耗一些 IO（和 CPU）周期，如果您不了解实时压缩，您会惊讶地发现。还有许多其他类似的组件可能会导致令人惊讶的行为，因为这些系统通常非常复杂。

希望这会有所帮助 - 很想知道您在基准测试方面的进展。我们在内部做了很多，发现系统在不同用例上的性能边界是一门艺术和一门科学。