翻译自官方wiki：https://github.com/facebook/rocksdb/wiki/Write-Stalls

转载请注明出处：https://www.cnblogs.com/morningli/p/16791706.html

write stall

当flush或compaction无法跟上写入的速率时，rocksdb有旁路系统来减慢写入速率。如果没有这样的系统，用户如果持续写入比硬件能处理的数据，数据库会发生下面的问题：

• 增加空间放大，会导致磁盘空间用光
• 增加读放大，严重损害读性能

这个想法是将写入减慢到数据库可以处理的速度。然而，有时候数据库会对临时的突发写过于敏感，或者低估了硬件的处理能力，所以你可能会看到预料外的慢或者查询超时。

为了找出你的数据库是否有write stall的问题，你可以检查：

• LOG文件，当write stall发生时会包含info日志
• 在LOG文件中找到 Compaction stats

write stall的原因

可能会因以下原因触发stall：

• 太多memtable。当等待flush的memtable的数量大于或者等于max_write_buffer_number，写入会完全停止写来等待flush结束。另外如果max_write_buffer_number 大于3，等待flush的memtable大于或等于max_write_buffer_number-1，写入则会stall。在这些情况下，你将在 LOG 文件中获得类似于以下内容的info日志：

  Stopping writes because we have 5 immutable memtables (waiting for flush), max_write_buffer_number is set to 5

  Stalling writes because we have 4 immutable memtables (waiting for flush), max_write_buffer_number is set to 5

• 太多0层sst文件。 当0层的sst文件数量达到level0_slowdown_writes_trigger， 写入则会stall。当0层的sst文件数量达到level0_stop_writes_trigger，写入会完全停止，等待0层到1层的compaction减少0层的文件数。在这些情况下，你将在 LOG 文件中获得类似于以下内容的info日志：

  Stalling writes because we have 4 level-0 files

  Stopping writes because we have 20 level-0 files

• 太多等待compaction的字节数。 当估计等待compaction的字节数达到soft_pending_compaction_bytes，写入则会stall。当评估等待的字节数达到hard_pending_compaction_bytes，写入会完全停止等待compaction。在这些情况下，你将在 LOG 文件中获得类似于以下内容的info日志：

  Stalling writes because of estimated pending compaction bytes 500000000

  Stopping writes because of estimated pending compaction bytes 1000000000

每当stall条件被触发，rocksdb会减少写速度到delayed_write_rate，如果等待compaction的字节还在增加，也有可能会减少到比delayed_write_rate更低。值得注意的一键式是减慢/停止的触发和等待compaction的字节数限制是每个column family单独配置的，但是write stall 是应用到整个数据库的，这意味着如果一个column family触发write stall，整个数据库都会被stall。

非阻塞写

如果触发了一个写减慢/停止，执行Put/Merge/Delete等的程序线程会被阻塞。如果一个减慢在生效中，每个写在处理之前会睡眠一段时间（一般是1ms）。如果写是stall的，线程可以无限制地阻塞。如果不希望线程被阻塞，应用可以通过在WriteOptions中设置no_slowdown = true来避免。在这个选项下，如果写请求因为减慢/stall导致没有完成，会立马返回Status::Incomplete()。

在内部，为了增加性能，rocksdb在写到WAL之前会尝试将来自不同线程的写入请求批处理在一起。然而设置了no_slowdown 的写请求不会这样做，这可能会导致轻微的性能损失。

减轻 write stall

有很多选项你可以调整来减轻write stall。如果你有一些负载可以接受write stall，有些不能，你可以设置一些写请求为 Low Priority Write 来避免延迟敏感的写请求被stall。

如果write stall是由待处理的flush引起的，你可以尝试：

• 增加 max_background_jobs 使用更多的flush线程
• 增加 max_write_buffer_number 减少flush的memtable大小（这里是不是写错了？？）

如果write stall是由太多0层文件或者太多等待compaction的字节数引起的，compaction跟不上写入的速度。请注意，任何减少写放大的操作都会减少compaction需要写入的字节数，从而加快压缩速度。尝试的选项：

• 增加 max_background_jobs 使用更多的compaction线程
• 增加write_buffer_size拥有更大的memable，减少写放大
• 增加min_write_buffer_number_to_merge

你可以设置停止/减慢触发器和待compacrion字节数限制为一个很大的数字来避免发生write stall。如果你正在批量导入数据到rocksdb也可以看一下在 FAQ 中的“What's the fastest way to load data into RocksDB?”。

写缓冲区管理器stall

WriteBufferManager 提供一个了选项allow_stall可以传递给WriteBufferManager的构造函数。如果设置为true，当内存使用超过buffer_size （软限制）时会stall所有写入。它将等待刷新完成并且内存使用量下降。应用可以通过在设置WriteOptions中设置no_slowdown = true来避免。