RocksDB中国語Wiki・Write Stallsのチューニング
2031 ワード
私たちがデータを大量に挿入し続けると、ある時間になると性能が突然低下し、突然このような状況が発生した場合、LOGファイルやstatisticsの上からwrite stallが発生したかどうかを確認します.
Where Stall
通常write stallはいくつかの場所で現れます
Too many memtables
flushからlevel 0まで待つmemtableがmax_を超えた場合write_buffer_number、RocksDBはflushが終わるまで完全にstopに書き込まれます.同時にmax_write_buffer_numberが3以上でflushを必要とするmemtableの数がmax_以上であるwriter_buffer_number-1の場合、RocksDBにはstallが書き込まれます.leveldbはmemtableとimmemtableが1つしかないので、これはありません.
Too many level-0 SST files
レベル0のSST fileの数がレベル0に達するとslowdown_writes_tiggerの場合、RocksDBにはstallが書き込まれます.レベル0のSST fileの数がレベル0に達するとstop_writes_triggerの場合、RocksDBはレベル0からレベル1までの間のcompactionが完了し、レベル0 SST fileの数が減少するまでstopに書き込まれます.
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があれば、1つの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を必要とするデータ量が小さくなるからです.次のことを試してみましょう
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...
Where Stall
通常write stallはいくつかの場所で現れます
Too many memtables
flushからlevel 0まで待つmemtableがmax_を超えた場合write_buffer_number、RocksDBはflushが終わるまで完全にstopに書き込まれます.同時にmax_write_buffer_numberが3以上でflushを必要とするmemtableの数がmax_以上であるwriter_buffer_number-1の場合、RocksDBにはstallが書き込まれます.leveldbはmemtableとimmemtableが1つしかないので、これはありません.
Too many level-0 SST files
レベル0のSST fileの数がレベル0に達するとslowdown_writes_tiggerの場合、RocksDBにはstallが書き込まれます.レベル0のSST fileの数がレベル0に達するとstop_writes_triggerの場合、RocksDBはレベル0からレベル1までの間のcompactionが完了し、レベル0 SST fileの数が減少するまでstopに書き込まれます.
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があれば、1つの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...