perf: maybe throttle concurrent compactions about pebble HOT 4 CLOSED

Concurrent compactions helps as long as the bottleneck is CPU, in which case parallelizing the work can increase the throughput. After reaching the point where the background rate limit is saturated, then I agree adding more parallelism is pointless and just slows down individual compactions. Ideally we can derive the amount of parallelism necessary for a given rate limit.

For preemption, I don't know. One of the goals of partitioned level compaction is to make individual compactions small enough that the LSM state doesn't change too much while that compaction is running. If it changes so much that we need to urgently switch to flush or L0->L1 to avoid write stalls, perhaps the compactions could be made smaller.

from pebble.

For preemption, I don't know. One of the goals of partitioned level compaction is to make individual compactions small enough that the LSM state doesn't change too much while that compaction is running. If it changes so much that we need to urgently switch to flush or L0->L1 to avoid write stalls, perhaps the compactions could be made smaller.

Small compactions make a lot of sense, yet we've previously debugged issues with super-large compactions that were created due to range deletion tombstones overlapping a significant portion of the key space.

from pebble.

While looking at the RocksDB mechanisms for pacing user-writes I noticed a mechanism for adjusting the compaction concurrency. The WriteController::GetCompactionPressureToken method is called when the system is approach a write stall condition. This is done by ColumnFamilyData::RecalculateWriteStallConditions. The compaction pressure token causes WriteController::NeedSpeedupCompaction to return true (that method also returns true if user-writes are stopped or throttled). NeedSpeedupCompaction controls whether DBImpl::GetBGJobLimits returns a value for max_compactions greater than 1. If NeedSpeedupCompaction() returns false, background compactions are throttled by only allowing 1 at a time.

The effect of all of these mechanisms is to only allow concurrent compactions if compactions are falling behind user writes.

from pebble.

The effect of all of these mechanisms is to only allow concurrent compactions if compactions are falling behind user writes.

That was originally introduced to handle the case where RocksDB is running in multiple processes on the same host (like multiple MyRocks instances) and there's no inter-process coordination for rate limiting. This way, each instance compacts at a low rate unless it really needs a high rate. Although, nothing prevents all the instances from needing a high rate simultaneously..

It's also a bit confusing to me to have rate limiting both on compaction parallelism and compaction writes. My dream is to limit compaction write rate only, and then calculate the minimum number of compaction threads necessary to utilize that rate.

from pebble.