Memory Management and Eviction: Difference between revisions
(Created page with "MemCP tracks persisted shard columns, indexes, temporary columns, keytables, cache-engine objects, and string dictionaries in a global memory manager. The overall budget defaults to 50% of system RAM. A separate persisted-data budget defaults to 30%. Exact byte limits override percentages. If system available memory falls too low, MemCP can evict before its own configured budget is exhausted. Eviction is LRU-like and type-aware. Persistent shard eviction releases only...") |
Wikiservice (talk | contribs) (Refresh MemCP documentation: accuracy, operational guidance, performance profile and maintained API reference) |
||
| Line 1: | Line 1: | ||
<!-- Copyright (C) 2026 Carl-Philip Haensch --> | |||
<!-- SPDX-License-Identifier: GPL-3.0-or-later --> | |||
= 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; | |||
* <code>memory</code> tables are never evicted, because RAM contains their only copy; | |||
* <code>cache</code> 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]]. | |||
Latest revision as of 11:59, 28 August 2026
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;
memorytables are never evicted, because RAM contains their only copy;cachetables 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.