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

时间:2014-11-25 05:14:55

标签: node.js performance resources database-performance rethinkdb

我问的是这个问题,因为我想了解如何更好地运行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配置是一切,插入只对一个只有一个分片和一个副本的表进行。请随意提出我可能忘记提及的任何相关内容。

提前致谢。

2 个答案:

答案 0 :(得分:4)

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

您可以尝试一些事项,但请注意,各种方法都有微妙之处。基准测试通常是 hard

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

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

答案 1 :(得分:3)

我的猜测是这里的瓶颈是磁盘系统,但不是它的吞吐量。更有可能的是,写入发生在太小而不能有效的块中,或者由于各个写入之间的延迟而导致延迟。 来自客户端的各个写入查询与服务器上的处理之间的延迟也可能会降低系统速度。

以下是我建议尝试的一些事项:

  • 进一步增加批量大小。你的文件非常小。因此,我认为批量1,000-10,000个文档可能会获得更高的吞吐量。这可能与下一点结合使用效果特别好。

  • 运行多个并发客户端。您提到您同时运行了2个客户端,但这可能还不够。如果可能,我建议运行16-32。

  • 检查RethinkDB正在使用的缓存大小。默认情况下,RethinkDB选择缓存大小作为可用内存的一小部分,但这并不总是可靠的。我建议将--cache-size <MB>参数传递给RethinkDB(或者将cache-size=<MB>参数添加到配置文件中,如果您使用的话)。我可以看到你的服务器有32 GB的RAM。我建议在20000 MB(甚至更多)的范围内使用缓存大小。较大的缓存会减少读取次数,但是达到某个限制也会增加RethinkDB可以在RAM中累积的未保存数据量,从而提高磁盘写入效率。

  • 试用--io-threads <THREADS>参数。默认值为64,但您可以尝试将其增加到例如128,看它是否有任何影响。