Memory Management and Eviction

Memory Management and Eviction

MemCP keeps compressed columns and execution structures close to the CPU, but it does not assume that every persistent byte must remain resident forever. A global memory manager accounts for persisted shard columns, indexes, temporary computed columns, keytables, cache-engine objects, and string dictionaries.

Budgets

The overall cache budget defaults to 50% of physical RAM. A separate persisted-data budget defaults to 30%. Exact byte limits can override percentages. MemCP may start eviction sooner when operating-system available memory becomes low, even if its configured budget has not yet been reached.

Budget enough headroom for the operating system, filesystem or object-store clients, connections, query intermediates, transaction deltas, rebuilds, and colocated services. The compressed database size alone is therefore not a safe RAM-sizing number.

What eviction means

Eviction is LRU-like and type-aware:

• persisted shard eviction releases only reloadable in-memory representations; column files remain intact;
• shards with unflushed deltas are not evicted;
• memory tables are never evicted, because RAM contains their only copy;
• cache tables are explicitly reconstructible and may be discarded under pressure;
• indexes and reusable computed structures can be rebuilt or reloaded according to their ownership.

Eviction is not table deletion and must never remove persistent files. A workload whose hot set exceeds the budget remains correct for persistent engines but may become I/O-bound as cold columns are loaded repeatedly.

Operating the cache

Watch resident and budgeted bytes together with eviction frequency, reload latency, storage-backend errors, delta growth, and query latency. Repeatedly evicting and reloading the same data indicates an undersized hot-set budget or a query pattern that touches too many columns. See Settings, Dashboard and Operations, Hardware Requirements, and Storage Backends.