node.js - 如何使用 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 需要什么才能运行得更快？为什么它不花费更多的资源并获得更高的吞吐量？

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

提前致谢。

Answer 1

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

您可以尝试一些方法，但请注意，各种方法都有微妙之处。一般来说，基准测试很难。

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

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