quickwit-oss / quickwit-oss/quickwit
MemorySizedCache could be leaking memory.
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 11.7k
- Forks
- 597
- Avg merge
- 2d 22h
- Merged PRs (30d)
- 37
Description
Describe the bug
While looking at the code to try to understand why ~1.4GB of heap memory appears unaccounted for in my production setup, I discovered that MemorySizedCache doesn't seem to take into account the size of the key. This is particularly problematic for LeafSearchCache which uses the (large) SearchRequest as a cache key.
On my production environment, the partial_request cache is the default 64MB, but from the metrics, I observe ~1 million entries for 35MB (35B per entry, the cache is half full). By my estimate, the SearchRequest, which includes the query AST, should be ~1400B per entry (~1.4GB for all the keys), which matches the ~1.4GB of unaccounted heap memory in my production setup.
- The
LeafSearchCachecache key is computed here. LeafSearchCacheuses a MemorySizedCache with the default LRU implementation- The LRU cache implementation doesn't take the key into account when putting an entry in the cache
Full disclaimer
I haven't been able to identify with certitude the root cause of my problem, this bug report is mostly based on my analysis of the code.
Steps to reproduce (if applicable)
I haven't been able to clearly reproduce/find a metric that point to the exact problem, but a unit test similar to this seems to pass, confirming my suspicion:
#[test]
fn test_key_size_is_not_accounted_for() {
let cache = MemorySizedCache::<String>::from_config(
&ByteSize::b(16).into(),
&CACHE_METRICS_FOR_TESTS,
);
let long_key = "k".repeat(1_000);
// The entry is stored even though key + value is ~1000 bytes, way above the 16 bytes capacity
cache.put(long_key.clone(), OwnedBytes::new(&b"0123456789"[..]));
}
Expected behavior
A partial request cache of size 64MB shouldn't need ~2GB of additional heap to store the keys.
Configuration:
quickwit version: 0.9.0 (x86_64-unknown-linux-gnu 2026-07-25T17:48:09Z cc420c3)
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in quickwit-storage/src/cache/base_cache.rs at the LRU put implementation, then trace the MemorySizedCache configuration and the LeafSearchCache key in quickwit-search/src/leaf_cache.rs. Run or adapt the reported test_key_size_is_not_accounted_for test; done means cache capacity accounts for both keys and values and the regression is covered.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- backend, performance
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 68/100