facebook / facebook/rocksdb

LRUCache strict_capacity=true

Open
#5,048 8 comments 0 reactions 0 assignees View on GitHub
Dominant language
C++
Stars
32.1k
Forks
6.9k
Avg merge
32m
Merged PRs (30d)
1

Description

We are not having any problems after I use rocksdb the way I described many times in this thread. Our read write load is very high and dB size is around terabytes. Still we are able to handle that with limited docker instance with 5gb ram limit including our Java app which is itself quite hungry. My guess is that rocksdb is taking max 2gb. All is running perfectly stable for months.

What I took as best for us:
1. Set Max open files! Yes it is a must.
2. Two level index.
3. Shared and strictly limited caches.
4. Jemalloc. It helps to keep memory stable. We have quite aggressive setup, but still no noticeable performance impact.
5. Directio for sequence scans.
6. Custom patches (Java specific)

All of these basically helps system and library. And it works perfectly. I use modified 5.12.5. Unfortunately patches that also helps a lot for high loads (Java direct buffers) were not merged. Otherwise jvm suffers from memory hot spots.

Anyway, rocksdb team, this is great work. I love this library.

_Originally posted by @koldat in https://github.com/facebook/rocksdb/issues/4112#issuecomment-470269235_

Contributor guide

Open the contributing guide

Research direction

The issue body contains a pasted discussion about RocksDB memory configuration but does not explain what strict_capacity=true should change. No file, test, or entry point is identified. First clarify the intended LRUCache behavior and acceptance criteria; the work is done only when those requirements are documented and testable.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
databases
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
15/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.