Archiveperformance
The Page Cache Is Your Best Database Cache
The kernel already keeps recently read files in RAM. Fighting it with application caches usually loses.
- Published
- Reading time
- 1 min read
On Linux, file reads populate the page cache; subsequent reads hit RAM. Writes go to dirty pages and are flushed asynchronously (unless O_DIRECT or fsync). Databases rely on this heavily.
Consequences
- Restarting a database does not necessarily mean cold reads; the OS cache survives process restarts.
freeshowing low "free" memory is normal — the cache is reclaimable.- Container memory limits count page cache; a database with a large buffer pool plus cache can hit the limit and trigger reclaim storms.
O_DIRECTbypasses the cache for databases that manage their own I/O, avoiding double caching but losing readahead benefits.
Tuning signals
Watch page-cache hit ratio, dirty page ratio, and reclaim activity. High major-fault rates and kswapd CPU suggest memory pressure, not disk speed.
Takeaway: size the buffer pool with the page cache in mind. Two caches holding the same pages is wasted memory; neither being warm is wasted I/O.