RocksDB write_buffer_size and max_write_buffer_number tuning under a fixed memory budget

RocksDB's documented defaults set write_buffer_size to 64 MiB per column family and max_write_buffer_number to 2. That is adequate for light local workloads, but under sustained production write traffic the memtable fills quickly, flushes queue up, and the write path stalls once the buffer count limit is reached.

The unresolved decision is how much memory to dedicate to memtables without exceeding the process budget. Total memtable memory scales roughly as write_buffer_size × max_write_buffer_number per column family, so an instance with many column families multiplies the footprint quickly. A larger buffer reduces flush frequency and write amplification, but an oversized setting risks OOM. It is unclear whether per-column-family tuning or a shared WriteBufferManager with db_write_buffer_size is the safer way to enforce a global memory cap.

Given a fixed RAM budget and a target write throughput, what sizing rule should guide write_buffer_size and max_write_buffer_number? When many column families share one instance, is a WriteBufferManager-based cap preferable to per-column-family buffer limits for avoiding write stalls?