Knees and plateaus in the miss-ratio curve

Where on the curve should a cache be sized, and how should shared capacity be split?

MRCs have knees, so sizing is not a smooth optimization

Real miss-ratio curves are not smooth. They have plateaus (adding capacity returns nothing) and cliffs (a little more capacity captures a whole loop or working set at once). The structure comes from Denning's working set: the set of items a job needs over a time window. If a job's working set is 8 GB, capacity below 8 GB buys almost nothing, and 8 GB buys everything.

Two practical consequences follow.

Land just past a cliff, never on a plateau. Provisioning just below a cliff is the worst position: you pay full price for capacity that returns nothing, and you are one working-set step away from a large free win. This is also why "we doubled the cache and nothing happened" is usually a correct observation about a plateau, not evidence that caching does not work.

For a shared cache, split capacity so the marginal hit rate is equal. Not equal capacity, and not equal hit rate. Greedy allocation against the slope of the curve, dMRC/dC (how fast the miss ratio falls per extra unit of cache), is the right procedure: give each tenant capacity until its slope matches the others'.

This is the honest answer to "how do I divide the cache between the OLTP workload and the analytics workload". It also tells you when the answer is do not share: if one tenant's stream is dominated by the one-shot component, its marginal return is near zero everywhere, so it should get a small fixed partition with admission filtering, not a fair share.

In one sentence: the curve is piecewise; size to just past a knee, and split shared capacity by equal marginal hit rate.