當我們持續大量插入資料的時候，會發現到了某一個時間，效能就突然下降了，如果突然出現了這樣的情況，我們都會從 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…