The page cache is the cache you already know, with pages for objects and page reads for requests: h = H(C,s)/H(N,s), and the disk still sees (1 − h) × reads. Sixty-four gigabytes over a five-hundred-gigabyte dataset is 12.80% of the pages and, at classic Zipf skew, about 88.9% of the reads — which is why “it is on disk, so every read is a disk read” is wrong by a factor of nine.
Core ideas
Nothing here is a new model. What is new is the vocabulary, and one property of the formula that decides how much memory is worth buying.
Caching and Hit Rates computed a hit rate from a cache size, a dataset size and a Zipf exponent. This is the same formula, called through the same function, with pages in place of objects and page reads in place of requests. The lesson is a callback: if you can size a cache you can size a page cache, and there is no second model to learn.
At classic Zipf skew, 12.80% of the pages carry about 88.9% of the reads — 6.9 times their share of the data. Uniform popularity would give exactly 12.80%, the share itself. Every argument for buying memory is an argument about the skew, and the skew is measurable rather than assumed.
A hit rate is a fraction and the disk is a device with an IOPS limit. At 20 000 page reads a second and h ≈ 88.905%, about 2 219 of them reach the disk; uniform popularity would send 17 440. Both are true of the same memory over the same data, and only the second sounds like a system in trouble.
The material
The same cache arithmetic in storage vocabulary, and what each doubling of memory actually buys.
The page cache holds C pages of a dataset of N pages in memory. Under Zipf popularity with exponent s, the hit rate is h = H(C,s)/H(N,s), where H(n,s) is the generalised harmonic number Σ 1/iˢ over i = 1…n.
The disk IOPS the workload leaves is (1 − h) × reads. At s = 0 the formula collapses to h = C/N, and every page is equally likely to be wanted.
Both sizes have to be converted into pages before anything else happens. At an 8 kB page a 500 GB dataset is 62 500 000 pages and 64 GB of memory is 8 000 000 of them, so C/N = 12.80%. The formula takes counts, not bytes, and a units error here moves the answer more than the skew does.
The two rows are the lesson. The same memory holding the same share of the same data serves about 88.9% of the reads when popularity is skewed and 12.8% when it is not, and the difference at the disk is a factor of nearly eight. Skew is not a detail of the workload; it is the reason the page cache exists.
Hold the dataset and the skew and walk the memory up by factors of two. From a sixty-fourth of the data to a half, the hit rate goes 77.553%, 81.294%, 85.036%, 88.777%, 92.518%, 96.259% — about 3.74 points every time. That is what H(C,1) growing like the logarithm of C looks like: equal multiples of memory buy equal absolute improvements.
The residual IOPS on those same six rows are 4 489, 3 741, 2 993, 2 245, 1 496 and 748. Each doubling removes about 748 IOPS — the same amount every time, not the same fraction. So the first doubling and the last one are worth the same to the disk, and the memory to buy them is thirty-two times more expensive on the last.
The hit rate on this page is rounded and the lab says so on its face. Past N = 40 pages the exact harmonic number is neither computable in a redraw nor readable when printed — its denominator grows far faster than the page — so h comes from a floating-point approximation to H(n,s). The lab prints the exact fraction at N = 40, C = 4 alongside, so the machinery producing the approximation is visible rather than asserted. At s = 0 the formula is C/N and stays exact at any size.
And the model is Zipf, which is a description of many real workloads and a description of none of them exactly. s is measured from a trace, not chosen; a real page cache also does read-ahead, which converts some misses into sequential reads that the IOPS figure treats too harshly, and holds dirty pages, which occupy C without serving reads. The arithmetic is the right first estimate and it is not a measurement.
Interactive
Memory over dataset, the skew, and the IOPS that are left
Method
Convert to pages, get the skew honestly, and then stay in the unit the device is limited by.
N = dataset/page and C = memory/page. At an 8 kB page, 500 GB is 62 500 000 pages and 64 GB is 8 000 000. The formula counts pages, and a mismatch of units here is the one error that changes the answer by orders of magnitude.
s is the Zipf exponent of your workload's page popularity, and it is the single most influential input: at s = 0 the hit rate is the share of the data and at s = 1 it is seven times that. Assuming s = 1 because it is the classic value is an assumption, and it should be labelled as one.
A hit rate is for describing the cache and a miss rate is for describing everything behind it. 88.905% and 11.095% are the same measurement, and only the second one multiplies into a device limit.
(1 − h) × reads is the IOPS the device must actually serve — 2 219 a second here. That is the number to hold against what the storage can do, and the number that tells you whether another doubling of memory is worth buying.
Convert to pages, apply the formula at two skews, and then walk the memory to see what each doubling is worth.
The two skew rows first. The same 12.80% of the data serves 88.9% of the reads under classic Zipf and 12.8% under uniform popularity, and the disk sees 2 219 IOPS against 17 440. Every sentence anyone writes about a page cache being effective is a sentence about the top row, and it is only true because real workloads are skewed.
Now read the last two rows across. Every doubling of memory adds about 3.74 points of hit rate and removes about 748 IOPS — the same amount each time, not the same fraction. That is H(C,1) growing like the logarithm of C, and it is why memory sizing is a question with a budget rather than a knee: there is no point at which another doubling suddenly stops helping, and no point at which it starts helping more.
For a faded rehearsal, halve the memory to 32 GB and keep everything else. The supplied first move is that C falls to 4 000 000 pages. Compute the hit rate and the residual IOPS, check them against the doubling rule above, and then say roughly how much memory it would take to get the disk below 1 500 IOPS. Run the lab at your answer before opening the quiz.
You should be able to convert a dataset and a memory size into pages, compute the hit rate at a stated skew, turn it into residual disk IOPS, and say what one more doubling of memory would buy in that unit.
Something to change about this lesson? Write it down, tick it off when it is handled, and export the list when you want to act on it. Kept in this browser only: nothing is sent anywhere, and nobody is notified.
No recommendations yet for this lesson.