-
Notifications
You must be signed in to change notification settings - Fork 6.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Out-of-memory during 'compact' the results of bulk-load (~=10TB) #11809
Comments
@ski422 Can you specify the RocksDB release you saw this on, as well as the exact command, and the OPTIONS and LOG files? |
I used RocksDB version 7.10.0 and executed ./tools/benchmark.sh as follow.
As you can find in benchmark.sh, bulk-load executes 'fillrandom' without auto-compaction and 'compact' to compact all files in level-0. Summarized adjusted options are as follows.
After the fillrandom is finished RocksDB created about 190 thousand of SST files in level-0. However, when the 'compact' is executed, it tries to read all SST files and it arises out-of-memory error. The OPTIONS and LOG files of 'compact' is as follows. . [Version] [DBOptions] [CFOptions "default"] [TableOptions/BlockBasedTable "default"]
|
My guess is the sheer number of files in L0 being compacted (~190K), and the compaction_readahead_size of 2MB, causes a lot of memory to be consumed by the compaction iterator. Can you run a heap profile to confirm? |
However, it looks like the default value of the compaction_readahead_size is 2MB and we cannot make it smaller. From what I've debugged, calling SeekToFirst() method of MergingIterator (inside of ProcessKeyValueCompaction) consumes all the memory. To be specific, the first for-loop (as below) in SeekToFirst() method (in table/merging_iterator.cc) was executing before out-of-memory.
|
Read ahead happens during the |
@cbi42 Thanks for your advise. However, can you please explain more details about 'split the bulk load into smaller batches'? I missed the term 'batch'. Is it about the compaction key range? Moreover, I'd appreciate it if you could tell me how to recude the compaction_readahead_size in the db_bench run. |
I meant load some L0 files and do compaction on them at a time, instead of loading all the L0 files and do a giant compaction.
You should be able to configure it with |
Hi to all Rocksdb users and dev group!
I experienced the out-of-memory while running 'compact' to compact the results of bulk-load (all SSTables are in level-0), and if anyone has experienced the same phenomenon, I'd like to ask for advice.
Goal
Loading 10TB of data on multiple SSDs in a single machine (all SSDs are controlled as raid-0). As a result of bulk-load, about 180~190 thousand of SSTables are written in level-0.
Behavior
After the bulk-load was finished, I tried to run 'compact' as described in ./tools/benchmark.sh script. However, the compaction tried to read the all SSTables into memory (I have 500GB), and it finally caused out-of-memory.
Question
Why does 'compact' try to read the entire level-0? Because of the 'compact' calls CompactRange() without specified range? or will the same phenomenon occur even if I designate the compaction range (since most of the key ranges overlap in level-0)?
It would be a great help if you could share your experience of trying to load more than a few TB of data.
The text was updated successfully, but these errors were encountered: