Filesystem Cache Calculator
Estimate page cache size needed to cache a working set of files in RAM.
About Filesystem Cache Calculator
The Linux page cache transparently keeps recently-read file data in unused RAM, so subsequent reads of the same data are served at RAM speed instead of disk speed — free -h's 'available' and 'cached' columns reflect this. This calculator estimates a simple hit rate as the fraction of your working set that fits in available cache RAM, then blends cache and disk latency by that ratio to estimate effective read latency, illustrating why adding RAM to cache a hot working set often beats upgrading disk speed for read-heavy workloads.
Formula
Effective read latency
effective_latency = cache_hit_rate × cache_latency + (1 − cache_hit_rate) × disk_latency
- h
- cache hit rate
- L_cache
- RAM/cache latency
- L_disk
- disk latency
Worked example
With the default values below, Filesystem Cache Calculator returns Estimated Cache Hit Rate of 64.0%. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Working Set Size (GB)minimum 0
- 50
- RAM Available for Page Cache (GB)minimum 0
- 32
- Cache (RAM) Read Latency (µs)minimum 0
- 1
- Disk Read Latency (µs)minimum 0
- 200
Results
- Estimated Cache Hit Rate
- 64.0%
- Effective Read Latency (µs)
- 72.64
- Speedup vs. All-Disk Reads
- 2.75
- Status
- Working set significantly exceeds available cache — expect frequent cache misses and disk-bound latency.
Step by step
- 1Values used
- 2Effective read latency
- 3Estimated Cache Hit Rate= 64.0
- 4Effective Read Latency (µs)= 72.64
- 5Speedup vs. All-Disk Reads= 2.75
- 6Status= Working set significantly exceeds available cache — expect frequent cache misses and disk-bound latency.
Assumptions and limits
- The result is derived only from the 4 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to 2 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
Frequently Asked Questions
Why does 'free -h' show most of my RAM as used even when applications are idle?
Linux aggressively uses spare RAM for page cache, since cached data can be instantly reclaimed if an application needs the memory. The 'available' column (not 'free') is the number that matters — it accounts for reclaimable cache and represents what's truly available for new allocations.
Does dropping caches free up 'real' memory?
Only in the sense that cached data isn't pinned — the kernel already reclaims it automatically under memory pressure without any action needed. Manually running `echo 3 > /proc/sys/vm/drop_caches` just discards useful cached data prematurely, typically hurting performance rather than helping it.
How much RAM do I need to fully cache my working set?
Enough RAM (after accounting for application and kernel memory needs) to hold your actively-accessed data — not your total disk usage. A database with a 2TB disk footprint but a 40GB 'hot' working set of frequently queried rows/indexes may perform excellently with just 64GB of RAM.