Skip to content

CONCEPT Cited by 1 source

Working-set memory

Definition

Working-set memory — the subset of a database's data + indexes that is actually accessed by the live query workload within a given time window and therefore needs to reside in memory for steady-state performance. Not the total dataset size and not the full index size — the hot slice of each.

A system where working-set > available cache pages in-and-out constantly, which means each query tends toward disk-latency rather than memory-latency. A system where working-set ≤ cache sits in an entirely different performance regime.

Informally: "the dataset that has to fit in RAM for the database to feel fast."

Common working-set shapes

  • Recent-time-window (write-heavy, time-ordered reads): only the last N hours / days of data is hot. Index on timestamp stays small in the active range; cold data is fine on disk. Most analytics / observability / IoT workloads.
  • High-cardinality hot tail (large product catalog, long tail of rarely-accessed items + small head of viral items): the top few % of keys dominate access. Working set is key-count-bounded, not data-size-bounded.
  • Broad low-locality (random reads across the dataset): no hot slice. Working set ≈ entire dataset. The hardest case — capacity planning requires RAM proportional to dataset size.
  • Index-heavy point lookups (unique-field lookups by secondary index): the index itself, not the data pages, is the hot slice. Common in transactional workloads.

Identifying which shape applies drives schema + index strategy.

Working-set vs WiredTiger cache

In MongoDB, "fit in WiredTiger cache" is the operational realization of "working-set fits in memory." The cache is usually ~50 % of system RAM; the OS filesystem cache layers below it; together they form the working-set residence tier.

Empirical diagnostic: observe eviction rate under representative load. Rising evictions under steady workload → working set doesn't fit. Flat evictions + high cache-hit ratio → it does.

MongoDB Cost of Not Knowing Part 3 specifically surfaces the index as the working-set component that didn't fit in appV6R0 (3.13 GB > 1.5 GB cache). Data pages were compressed enough to fit fine; the _id B-tree wasn't.

Levers to fit working set in memory

Roughly in order of first-pass preference:

  1. Shrink the schema (what MongoDB's Cost of Not Knowing series does — field-name shortening, data-type tightening, bucket pattern, computed pattern, dynamic schema).
  2. Right-size the bucket window — wider buckets = fewer documents = smaller index. The appV6R0 → appV6R1 pivot.
  3. Drop unnecessary secondary indexes. Every additional index adds its own B-tree to the working set.
  4. Add RAM. Obvious and sometimes correct, but typically the least-efficient lever — cloud RAM costs 10× a storage byte.
  5. Shard. Splits working set across machines. Expensive in operational complexity; last resort.
  • Working-set vs total dataset. Total dataset is the full on-disk footprint; working set is the hot slice. Capacity planning cares about working set; durability planning cares about total.
  • concepts/cache-locality — the code-level analogue: CPU cache working set. Same principle (hot subset fits in fast tier); different tier.
  • concepts/disk-throughput-bottleneck — disk throughput is the symptom when working set doesn't fit. The bottleneck class is usually the signal; working-set sizing is the fix.

Seen in

Last updated · 200 distilled / 1,178 read