Scenarios

RAM must cover the buffer pool, working memory, the page cache and overhead. A 200 GB heap leaves about 56 GB for the page cache, thread stacks, direct buffers and the operating system, so any growth there pushes the machine over.

The kernel chooses what to swap by recency, so it will push out hash-table pages that merely look cold between probes. The job turns a clean failure into a crawl: hours instead of minutes.

Size the four claimants explicitly: a heap well below total RAM, and separate budgets for off-heap buffers and the page cache. Decide whether direct I/O avoids double buffering. Move large, uniform, long-lived data off-heap, and ration the working memory of concurrent queries.

The risk of leaks and out-of-memory errors moves into your own accounting.

60 GB as about 600 million small objects, traced at 10⁸–10⁹ references per second per thread, is seconds of marking per collection. Concurrent collectors move that cost onto the CPU, 10–20% of throughput, rather than removing it.

If the data is large, long-lived and uniform in shape, store it in a few large direct buffers with fixed-offset records, freed by explicit reference counting, and keep the rest of the heap small and tuned for short-lived objects.

You now own layout, serialization and lifetime, and leaks and use-after-free bugs are silent.

When objects are small and short-lived (allocation in the young generation is a pointer bump, and copying across the boundary can cost more), or when the live set is already small and the problem is allocation churn: tune the young generation and stop. On JDK 8 the low-pause collectors are not available, so moving off-heap pays at a smaller live set.

1. External fragmentation in the allocator: free memory exists but not in contiguous pieces, common in long-running workloads with mixed sizes. Compare resident memory with live bytes from the allocator's statistics.
2. An unbounded intern table or dictionary: live state that never shrinks. Track its size over time.
3. A reference held longer than the pipeline needs, such as a slow consumer pinning a shared buffer.

An arena per execution phase with an explicit reset point (bounded fragmentation and cheap allocation, paid for in peak memory held); dictionaries with a cap and a fallback to plain encoding; and audits of who owns each buffer.

Arenas need a clear phase boundary; without one, you have a leak with a bump pointer.

Declare them: give scans a ring of buffers so they never enter the main pool. That beats any adaptive policy.

With dozens of cores hitting the pool at once, synchronization on the hit path dominates, so use Clock (or a sharded Clock) rather than LRU, whose list head becomes a contended cache line.

If you can afford about twice the metadata, 2Q or ARC, with ghost entries, protects pages seen twice and adapts between recency and frequency. Check licensing, and note that ARC still changes lists on hits.

Replay a trace against Belady's MIN to see whether a 60% hit rate is a policy failure or a capacity failure. If capacity, use the five-minute rule to judge the value of more RAM before buying it.

Size the pool on usable frames (minus pinned frames and dirty frames waiting on the log), and use explicit huge pages with transparent huge pages off.

Write-ahead logging needs the engine to decide when a dirty page may reach disk. With mmap the kernel decides, so the rule cannot be enforced.

Page-fault I/O is invisible to the engine, so stalls happen inside critical sections that assumed memory speed; errors arrive as SIGBUS; and TLB shootdowns cost more as cores increase.

The five-minute rule: with 8 KB pages (128 per MB), and illustrative prices of $0.003 per access-per-second and $0.003 per MB of RAM, the break-even is (128 × 0.003) ÷ 0.003 = 128 seconds. Pages touched every few minutes belong in RAM and colder ones do not, so some residency policy is always needed, however cheap RAM gets.

The engineering complaint, buffer-pool overhead, is real. It is answered by pointer swizzling, not by deleting the pool.

100 GB ÷ 4 KB ≈ 26 million page-table entries, while a TLB of about 1,500 entries covers only about 6 MB. Nearly every access to a new page is a TLB miss, followed by a dependent page-table walk of 20–100 cycles.

Back the pool with 2 MB huge pages, which multiply the TLB's reach about 500×, to roughly 3 GB for 1,536 entries.

Use explicit, reserved huge pages and turn transparent huge pages off: their background compaction causes stalls of tens of milliseconds, improving the mean but ruining the variance.

With TLB-miss counters (perf stat) before and after. The pool's own page size (4–32 KB) is a separate decision, about read amplification, not the TLB.

It over-commits: queries allocate as they go, and the victim is whoever allocates last, not whoever holds the most. Add grants and an admission gate that counts bytes, so failures happen at admission, with a clear cause.

It over-reserves: grants come from estimates an order of magnitude too high, so memory is reserved and never touched. Measure actual peak against grant for each plan, feed that back to shrink future grants, and size grants at merge-pass boundaries.

Cap memory per query to limit the damage any one can do. The trade-off is isolation against utilization; because Monday peaks are correlated (a batch window), reservation rather than over-commit is the right position. Also look for memory holders the system cannot see, such as UDFs, which set the size of the reserve.

With memory at 100 GB/s and NVMe at 2 GB/s, the ratio r is 50, so (1 − 0.05) + 2 × 0.05 × 50 = 5.95, about 6×. The result is expected, not a bug.

Faster disks help only in proportion to r.

A larger grant, at the next pass boundary; LZ4 compression of the spill (about 3:1, which divides the dominant term by 3); and grant feedback, so the next run is sized right.

If the spill disk is network-attached, r is about 500 and the same spill costs about 51×.

Compression and feedback first, hardware last.

The terminal case of skew: no hash function can split one key, so recursive partitioning never converges.

If the aggregate is SUM, COUNT, MIN or MAX, aggregate partially: each group's state is constant-sized, and nothing needs to spill.

For an exact median or distinct count: fall back to sort-merge for the oversized partition (it always terminates, at the cost of a log factor and a second code path); plan for skew by detecting hot keys from statistics and handling them separately (relying on statistics that are weakest exactly at the tail); or use an approximate sketch.

Reformulating first: it costs nothing.

Memory was gated, but spill bandwidth was not. Under correlated pressure, every query spills to the same local device. With a 1.5 GB/s drive and 0.3 GB/s per query, four queries put it at 80% utilization, a 5× response time, and a fifth pushes it past 100%.

Spilling makes queries take longer, so by Little's Law more are in flight holding grants: the relief feeds the pressure.

Limit how many queries may spill at once, sized to keep the device below about 70% utilization, and queue the rest. Compress spill, and consider a kill rule at a hard watermark.

Some queries wait instead of crawling, but the device does not collapse.

Fail a query before the kernel fails a process: losing an executor destroys cached blocks and shuffle output and forces recomputation upstream.

Two thresholds with hysteresis: at the soft one, ask consumers to spill; at the hard one, stop admitting, then kill. Size the reserve from spill latency and from memory holders the system cannot see (UDFs, libraries).

Keep an inventory of operators that cannot spill (unbounded window frames, holistic aggregates, UDF state, broadcast hash tables): they are the kill candidates.

Killing the requester loses the least work; killing the largest holder frees the most. Each just moves the cost somewhere.

Feed kills back into grant sizing, so the retry gets a larger grant.

Container memory limits cap capacity, not memory bandwidth or the shared last-level cache. A scan with no reuse evicts the shared cache and saturates the memory controller, so the dashboard's latency rises along the 1 / (1 − ρ) curve while both tenants stay within their limits.

Put the workloads on different sockets or nodes (simple, costs utilization); limit the scan's threads; or use hardware partitioning of cache and bandwidth, such as Intel RDT, which exists but is rarely used outside very large fleets.

Isolate by placement now, and measure memory bandwidth per socket so the problem becomes visible.