当我们持续大量插入数据的时候，会发现到了某一个时间，性能就突然下降了，如果突然出现了这样的情况，我们都会从 LOG 文件里或者 statistics 上面来确认是否出现了 write stall。

Where Stall

通常 write stall 会在几个地方出现

Too many memtables

当需要等待被 flush 到 level 0 的 memtable 到了或者超过了 max_write_buffer_number，RocksDB 就会完全 stop 写入，直到 flush 结束。同时，当 max_write_buffer_number 大于等于 3，需要 flush 的 memtable 数量已经大于等于 max_writer_buffer_number – 1 的时候，RocksDB 就会 stall 写入。leveldb因为只会有一个memtable和immemtable，所以没有这个。

Too many level-0 SST files

当 level 0 的 SST file 的数量达到 level0_slowdown_writes_tigger 的时候，RocksDB 就会 stall 写入。当 level 0 的 SST file 的数量达到 level0_stop_writes_trigger 的时候，RocksDB 就会 stop 写入，直到 level 0 到 level 1 之间的 compaction 完成，level 0 SST file 的数量减少之后。

Too many pending compaction bytes

当预计的 compaction 数据的大小达到了 sofe_pending_compaction_bytes 之后，RocksDB 会 stall 写入。当达到了 hard_pending_compaction_bytes 之后，则会 stop 写入。这个机制是leveldb所没有的。

Mitigate Stall

我们并不能杜绝 stall，只能通过配置尽量的改善。
当发生 stall 的时候，RocksDB 会降低写入的速度到 delayed_write_rate，甚至有可能比这个更低。另外需要注意的是 slowdown/stop trigger 或者 pending compaction limit 都是针对不同的 CF 的，但 stall 是针对整个 DB 的，如果程序里面有多个 CF，一个 CF 出现了 stall 的情况，整个 DB 都会 stall。
如果 stall 是因为 pending flush memtable 不及时导致的，我们可以尝试:
增大 max_background_flushes ，这样就能有更多的线程同时 flush memtable。
增大 max_write_buffer_number ，用更小的 memtable 来提升 flush 的速度。
如果 stall 是因为 level 0 或者 pending compaction 太多导致，我们就需要考虑提升 compaction 的速度。另外，也可以减小写放大，因为写放大越小，需要 compaction 的数据量就越小。所以我们可以尝试：

        增大 max_background_compactions，用更多的线程来进行 compaction。

增大 write_buffer_size，这样就能有更大的 memtable，用来减少写放大。
增加 min_write_buffer_number_to_merge，在 flush 之前先将 memtable merge，减少写入 key 的数量，但这样会影响从 memtable read 的性能。

RocksDB中文Wiki地址：https://github.com/cld3786326…
英文原文：https://github.com/facebook/r…