-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Open
Labels
Description
Is your feature request related to a problem?
Yes. In LiteDB v5 the MemoryCache can grow without clear limits (see issues #1756 and #2619).
This leads to unpredictable RAM usage in long-running applications.
Even if workloads are moderate the cache can retain too many free pages and slowly consume all available memory.
Describe the solution you'd like
Introduce a hardened MemoryCache design for v6 with:
- Non-reentrant cleanup (prevent overlapping runs)
- Atomic eviction flag on pages (avoid use-after-free)
- On-demand cleanup trigger when free-list exceeds MaxFreePages
- Safe disposal with cancellation
- Conservative defaults (safe for production workloads)
- Lightweight metrics (FreeCount, EvictedPages, etc.)
- (Optional, opt-in) Byte caps and watermarks (MaxCacheSizeBytes, High/LowWatermarkBytes) for predictable memory ceilings
Describe alternatives you've considered
- Keeping the current design: not ideal, memory growth remains unpredictable
- Application-level workarounds (manual eviction, limiting usage): fragile and inconsistent
- A complete redesign (e.g., full LRU): too complex and may break compatibility
Additional context
- POC branch with experiments and stress testing (500 documents of 50MB, multi-terminal system load). Results show stable memory with bounded cache.
- Proposed roadmap: 3 incremental PRs (Hardening → Observability → Byte Caps/Watermarks)
- References: