{"id":1122,"date":"2026-09-13T23:10:28","date_gmt":"2026-09-13T23:10:28","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=1122"},"modified":"2026-09-16T22:03:40","modified_gmt":"2026-09-16T22:03:40","slug":"kernel-page-cache-small-vps-behaviour","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/kernel-page-cache-small-vps-behaviour\/","title":{"rendered":"Kernel Page Cache on a Small VPS: What Is Actually Cached, and How to Prove It"},"content":{"rendered":"\n\n

On a 2 GB VPS, the difference between a fast site and a slow one is usually not CPU. It is whether the files your application reads most often are already in RAM when the request arrives. The kernel page cache is what makes that possible, and it is also the most misunderstood subsystem on small instances \u2014 the same cache that delivers a 10x speedup on a warm database also causes the mysterious latency spike after a backup job evicts everything. This article explains the mechanism, then gives you measurements that decide whether you need more RAM or better access patterns. If your plan choice is still open, the cloud VPS feature set<\/a> matters here mainly for one number: how much RAM you can actually allocate to cache.<\/p>\n\n\n\n

Read the right numbers in \/proc\/meminfo<\/h2>\n\n\n\n

free -h<\/code> is the tool everyone runs and the tool that misleads most often, because on Linux “used” memory excludes cache \u2014 a healthy system shows almost no free RAM by design. Look instead at the breakdown:<\/p>\n\n\n\n

grep -E '^(MemTotal|MemFree|MemAvailable|Buffers|Cached|Dirty|Writeback|AnonPages|SReclaimable)' \/proc\/meminfo<\/code><\/pre>\n\n\n\n
Field<\/th>What it means<\/th>Healthy on a small VPS<\/th><\/tr><\/thead>
MemAvailable<\/code><\/td>RAM obtainable without swapping<\/td>> 15% of total<\/td><\/tr>
Cached<\/code><\/td>Page cache (file-backed pages)<\/td>Large is good<\/em> \u2014 it is reclaimable<\/td><\/tr>
Dirty<\/code><\/td>Modified pages not yet written to disk<\/td>< dirty_ratio<\/code> \u00d7 total<\/td><\/tr>
Writeback<\/code><\/td>Pages actively being flushed<\/td>Bursty; sustained high = disk too slow<\/td><\/tr>
AnonPages<\/code><\/td>Process RSS that cannot be reclaimed<\/td>Stable; growth means a leak<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
The practical takeaway: high Cached<\/code> is not a problem. High Dirty<\/code> with a slow device is, because those pages must eventually be written, and the flush blocks allocations under memory pressure.<\/p>\n\n\n\n
How reclaim actually proceeds when RAM runs low<\/h2>\n\n\n\n
When a process needs a page and free memory is tight, the kernel reclaims in a defined order. Understanding it prevents you from “fixing” the wrong layer:<\/p>\n\n\n\n
    \n
  1. Clean page cache<\/strong> \u2014 file pages already written to disk. Free to discard. This is why dropping caches is usually a no-op on a healthy system, and why doing it manually is actively harmful: you throw away warm data that took hours to accumulate.<\/li>\n\n\n\n
  2. Reclaimable slab<\/strong> (SReclaimable<\/code>) \u2014 inode and dentry caches, filesystem metadata. Cheap to reclaim, cheap to rebuild.<\/li>\n\n\n\n
  3. Dirty page writeback<\/strong> \u2014 must be flushed before reclaim. This is the step that stalls.<\/li>\n\n\n\n
  4. Anonymous pages \u2192 swap<\/strong> \u2014 process memory pushed to disk. Now latency is measured in tens of milliseconds per access.<\/li>\n\n\n\n
  5. OOM killer<\/strong> \u2014 a process dies.<\/li>\n<\/ol>\n\n\n\n
    Steps 3 through 5 are where small-VPS performance collapses. The goal of tuning is to keep the system operating in steps 1 and 2.<\/p>\n\n\n\n
    Measure whether your working set fits<\/h2>\n\n\n\n
    This is the single most useful page-cache diagnostic: the ratio of page requests served from cache versus from disk, per process.<\/p>\n\n\n\n
    # Minor (cache hit) vs major (disk read) page faults for MySQL\nps -o pid,min_flt,maj_flt,cmd -C mysqld\n\n# Watch the delta over 60 seconds instead of the lifetime total\nwhile true; do\n  ps -o maj_flt= -C mysqld\n  sleep 60\ndone<\/code><\/pre>\n\n\n\n
    maj_flt<\/code> is the count of faults that required a physical disk read. If that counter is climbing steadily on an otherwise idle system, the cache is being churned and every database read is reaching the device. Watch the delta, not the lifetime figure \u2014 the lifetime number is meaningless after a few days of uptime.<\/p>\n\n\n\n
    Pair it with the kernel’s own pressure signal, which is the best early-warning metric most people have never read:<\/p>\n\n\n\n
    cat \/proc\/pressure\/memory\n# some avg10=0.00 avg60=1.42 avg300=0.61 total=88213\n# full avg10=0.00 avg60=0.00 avg300=0.00 total=1993<\/code><\/pre>\n\n\n\n
    some<\/code> means at least one task was stalled on memory. full<\/code> means all<\/em> runnable tasks were stalled simultaneously \u2014 the system was effectively frozen. Sustained full<\/code> above 0.5% on a web server is a real problem, and it will not show up in load average or CPU graphs at all.<\/p>\n\n\n\n
    The dirty page problem on slow storage<\/h2>\n\n\n\n
    Dirty pages generate write latency, and on a shared-tier VPS with an I\/O quota, they generate throttling. Two sysctls control when the kernel starts and stops flushing:<\/p>\n\n\n\n
    sysctl vm.dirty_ratio vm.dirty_background_ratio vm.dirty_expire_centisecs vm.dirty_writeback_centisecs\n\n# Tighter bounds for a slow or metered device (2 GB RAM example):\nvm.dirty_background_ratio = 5     # start background flush at ~100 MB\nvm.dirty_ratio = 15               # force synchronous flush at ~300 MB\nvm.dirty_expire_centisecs = 1500  # flush pages older than 15 s\nvm.dirty_writeback_centisecs = 500<\/code><\/pre>\n\n\n\n
    The trade-off is explicit. Higher dirty_ratio<\/code> batches writes efficiently \u2014 better throughput \u2014 but creates a large reservoir of unflushed data that turns into a multi-second stall when it must be written all at once. On a device with a hard IOPS ceiling, the batching benefit is illusory because you cannot drain the reservoir faster than the throttle allows. Lower values keep write latency smooth at the cost of slightly more, smaller write operations.<\/p>\n\n\n\n
    Pair this with vm.swappiness<\/code>. The default of 60 is tuned for general-purpose systems; on a database host where you want file pages kept and anonymous pages pushed out only under genuine pressure, values of 10\u201320 are more appropriate. The interaction is covered in our swappiness tuning article<\/a> \u2014 the short version is that swappiness affects the page cache\/anon balance, and on a small VPS that balance is the difference between cached reads and disk reads.<\/p>\n\n\n\n
    What not to do<\/h2>\n\n\n\n