Repository navigation
Full RocksDB compaction causes OOM kill — memory usage undocumented #215
Description
The periodic full compaction on the history RocksDB database consumes significantly more memory than normal operation, often leading to OOM kills on machines that otherwise have plenty of RAM for steady-state indexing. The memory requirements for full compaction are not documented anywhere.
Environment
electrs version: built from source
OS: Ubuntu 24, systemd managed
RAM: 16 GB
Mode: --lightmode with --jsonrpc-import
RocksDB settings: --db-write-buffer-size-mb 64, --db-block-cache-mb 128, --db-parallelism 1
Relevant logs
INFO starting full compaction on RocksDB { path: "/home/ubuntu/.electrs/db/mainnet/newindex/history" }
electrs.service: A process of this unit has been killed by the OOM killer.
electrs.service: Failed with result 'oom-kill'.
electrs.service: Consumed 1h 22min 3.542s CPU time, 15G memory peak.
I tried to resolve this by Setting systemd MemoryHigh=10G and MemoryMax=12G to throttle rather than OOM-kill. But it seem like it will never end the compaction process:
May 07 06:16:14 btc-node electrs[234837]: INFO Salt rotated
May 06 09:24:26 btc-node electrs[234837]: INFO starting full compaction on RocksDB { path: "/home/ubuntu/.electrs/db/mainnet/newindex/history" }
May 06 06:16:33 btc-node electrs[234837]: INFO processing blocks 948088/948125 (100.0%)
May 06 06:16:29 btc-node electrs[234837]: INFO fetching blocks 948088/948125 (100.0%)
Questions
- How much memory does full compaction actually require?
- Would it be possible to document minimum memory requirements for full compaction, especially for mainnet?
THX!
Activity
EddieHouston commentedon May 21, 2026
There should not be any periodic full compaction happening. The "starting full compaction" only happens on first startup and not during steady state running after that initial sync and compaction complete.
We currently use machines with at least 64 GB for initial full sync and compaction of mainnet. There are a few configuration knobs you can change (e.g. making -db-write-buffer-size-mb larger so it creates fewer SSTs could be interesting), but 16G is probably still too small. It's possible there are some other internal configuration knobs in RocksDB to expose in the future to help fit into smaller memory footprint (still with tradeoffs for speed).
On question 2, yes. Definitely is needed to document the current minimum memory requirements. There are a few more enhancements coming in the next month or so and we will characterize it and document minimums once this is completed.
One other thing you can try, is to use an older build of Electrs, like commit 335b567
This is one commit before we sped up the initial sync with PR #195 and thus increased memory requirements.