Comments (4)
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.
Related Issues (20)
- [ignore] Testing sync
- github.com/cockroachdb/pebble/internal/metamorphic: TestMeta failed HOT 3
- prototype modular bloom filters HOT 1
- db: offload downloads to objprovider to reduce cache and db.mu churn
- github.com/cockroachdb/pebble/internal/metamorphic: TestMeta failed HOT 4
- : failed HOT 7
- db: Download should use block cache for metadata/index block lookups
- github.com/cockroachdb/pebble/internal/metamorphic: TestMetaTwoInstance failed
- don't use filter blocks for large flushable ingests HOT 1
- smart filter block loading
- improve performance of aggregations over a key range using range annotations
- db: strictly enforce prefix in internalIterator.SeekPrefixGE
- sstable: show filenum when sstable metadata is corrupted
- db: shared compaction concurrency limit across multiple Pebble instances HOT 2
- db: add ability to excise without ingest HOT 1
- github.com/cockroachdb/pebble/internal/metamorphic: TestMeta failed HOT 10
- add ValidateKey method to comparer
- ingest: verify ingestion sstables have legal boundary range keys
- internal/metamorphic/crossversion/crossversion_test: TestMetaCrossVersion failed HOT 1
- Backup HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pebble.