写停滞

当刷新或压缩不能跟上传入的写速率时，RocksDB具有广泛的系统来降低写速度。 如果没有这样的系统，如果用户继续编写超出硬件处理能力的代码，数据库将:

  1. 1.增加空间放大，这可能导致耗尽磁盘空间。
  2. 2.增加读取放大，显著降低读取性能。

其思想是将传入的写降低到数据库能够处理的速度。但是，有时数据库可能对临时写突发过于敏感，或者低估了硬件的处理能力， 因此可能会出现意外的慢速或查询超时。

要了解你的数据库是否有写停止问题，您可以查看:

  1. * LOG文件，当写停止触发时将包含信息日志；
  2. * 在LOG文件中找到压缩状态。

停滞可能会因下列原因被触发:

  • Too many memtables. 太多的memtables 当等待刷新的memtables的数量大于或等于max_write_buffer_number时，将完全停止写操作，等待刷新完成。 此外，如果max_write_buffer_number大于3，并且等待刷新的memtables的数量大于或等于max_write_buffer_number - 1，那么写入就会停止，在这些情况下，您会得到信息日志在日志文件类似:

    • Stopping writes 因为我们有5个不可变的memtables(等待刷新)，所以max_write_buffer_number被设置为5
    • Stalling writes 因为我们有4个不可变的memtables(等待刷新)，所以max_write_buffer_number被设置为5

  • Too many level-0 SST files. level-0 太多的SST文件 当级别为0的SST文件数量达到level0_slowdown_writes_rigger时，写入将停止。 当级别0的SST文件数量达到level0_stop_writes_trigger时，将完全停止写操作，等待级别0到级别1的压缩，从而减少级别0文件的数量。 在这些情况下，您将在类似的日志文件中获得信息日志

    • Stalling writes 因为我们有4个0级文件，所以导致写操作停滞
    • Stopping writes 因为我们有20个0级文件，所以到至停止写

  • Too many pending compaction bytes. 太多待定压缩字节

    当预估的待压缩字节数达到soft_pending_compaction_bytes时，写操作将停止。 当预估的待压缩字节达到hard_pending_compaction_bytes时，write写操作将完全停止， 等待压缩。在这些情况下，您将在类似的日志文件中获得信息日志

    • 由于预估的暂挂压缩字节500000000，而导致写操作停滞
    • 由于预估的暂挂压缩字节1000000000，而停止写操作

无论何时触发失速条件，RocksDB 都会将写速率降低到delayed_write_rate，并且如果预估的未决要字节累积起来，则有可能将写速率降低到甚至低于delayed_write_rate。 值得注意的一件事是，减速/停止触发器和挂起的压缩字节限制是每个列族的，写停滞适用于整个DB，这意味着如果一个列族触发写停滞，整个DB将停止。

您可以调优多个选项来缓解写延迟。如果您有一些工作负载可以荣恩写停滞，而有些则不能，那么您可以将一些写喜设置为低优先级的写，以避免在那些延迟关键的写中出现停滞。

如果写停滞是由挂起刷新触发的，您可以尝试:

  • 增加 max_background_flushes 已获得更多的刷新线程
  • 增加 max_write_buffer_number 使要刷新的memtable更小。

如果过多的0级文件或过多的暂挂压缩字节触发了写停止，那么压缩的速度不足以赶上写。注意，任何减少写放大的操作都会减少压缩所需额字节数，从而加快压缩。选择尝试:

  • 增加 max_background_compactions 已获得更多的压缩线程。
  • 增加 write_buffer_size以拥有较大的memtable，以减少写放大。
  • 增加 min_write_buffer_number_to_merge。

您还可以将停止/减速触发器和挂起的压缩字节限制设置为巨大的数字，以避免出现写停滞。如果您正在批量加载数据到RocksDB,请在我们的FAQ中查看”将数据加载到RocksDB的最快方法是什么?”