Filesystem Cache Calculator
Estimate page cache size needed to cache a working set of files in RAM.
Inputs
~100-200µs for SSD, ~5000-10000µs for HDD
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
Values used
Working Set Size (GB) = 50; RAM Available for Page Cache (GB) = 32; Cache (RAM) Read Latency (µs) = 1; Disk Read Latency (µs) = 200
Effective read latency
effective_latency = cache_hit_rate × cache_latency + (1 − cache_hit_rate) × disk_latency
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.
How it works
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
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.