RocksDB中文Wiki·Write Stalls的调优

当我们持续大量插入数据的时候,会发现到了某一个时间,性能就突然下降了,如果突然出现了这样的情况,我们都会从 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...

你可能感兴趣的:(nosql)