Tuning Linux File Cache Pressure (vm.vfs_cache_pressure) on a VPS

vm.vfs_cache_pressure controls how aggressively the kernel reclaims dentry and inode caches relative to page cache. Most tuning guides set it to 50 or 200 without explaining what it actually changes. On a small VPS serving many small files — WordPress, a git server, a container host — getting this wrong means either constant inode re-lookups or stalled directory traversal. This article explains the mechanism and how to measure it.

What the parameter really does

The value is a scaling percentage, not a hard target. At 100 the kernel balances reclaim between dentry/inode slabs and page cache proportionally to their size. Below 100 (e.g. 50) the kernel keeps dentries and inodes longer — it is less pressured to evict them. Above 100 (e.g. 200) it evicts them more eagerly, favouring page cache. The name is misleading: higher value = higher pressure = faster eviction of the directory caches.

# current value and where it lives
sysctl vm.vfs_cache_pressure
cat /proc/sys/vm/vfs_cache_pressure

# persistent drop-in (recommended over editing sysctl.conf)
cat >/etc/sysctl.d/60-vfs-cache.conf <<'EOF'
vm.vfs_cache_pressure=50
EOF
sysctl --system

Watch the slabs

Dentries and inodes are exposed via slabinfo. Track dentry and ext4_inode_cache (or the btrfs equivalents) over time:

# object counts and memory per cache
grep -E 'dentry|inode_cache' /proc/slabinfo | awk '{print $1,$2,$3,$4*$5/1024" KB"}'

# total reclaimable slab memory
cat /proc/meminfo | grep -E 'Slab|SReclaimable|SUnreclaim'

On a host serving thousands of small files, a healthy configuration shows dentry and inode slabs growing to a stable plateau and SReclaimable accounting for most of the slab. If SUnreclaim dominates, you have a kernel leak, not a cache-pressure problem — lowering pressure will not help, and you must not raise it.

Measure the effect, don’t guess

Use a filesystem-walk benchmark that stresses the dentry cache, then compare at different pressure values. Drop caches between runs so each starts cold:

# cold-cache directory traversal
echo 3 > /proc/sys/vm/drop_caches
/usr/bin/time -v find /var/www -type f -printf '' 2>&1 | grep -E 'wall clock|Minor'

# stat every file, forces inode lookups
find /var/www -type f -exec stat -c '%i %s' {} + >/dev/null

# repeat with the other value
sysctl -w vm.vfs_cache_pressure=200

On typical web workloads the difference is real but modest: a warm dentry cache can cut find wall time by 30–50% versus a cold one, and keeping it warm across bursts of traffic avoids repeated inode lookups. Lowering pressure to 50 helps when your working set of paths fits in RAM but your workload is path-heavy. It does not help when the working set exceeds memory — then you are simply trading page cache for metadata and may slow file reads.

Interaction with swappiness and dirty ratios

• vm.swappiness decides anonymous vs file-backed reclaim; vfs_cache_pressure then splits the file-backed side.
• vm.dirty_ratio / vm.dirty_background_ratio gate writeback and can dominate behaviour under heavy writes regardless of cache pressure.
• On a small VPS, set swappiness low (10–20) with a pressure of 50 for a path-heavy app, and always confirm with slab counters rather than trusting the number.

Because these tunables only matter when memory is genuinely constrained, they are most effective on small instances where RAM is the bottleneck. When you outgrow 1–2 GB, more memory solves more than any sysctl — compare VPS hosting providers and size the plan to your file-path working set before you spend hours micro-tuning.

Bottom line: treat vm.vfs_cache_pressure as a dial that trades metadata cache for page cache, validate every change against /proc/slabinfo and a cold-cache filesystem walk, and leave it at 100 unless your measurements show a clear win.

Sponsored: if you need a VPS with predictable memory and no hidden steals, InterServer VPS plans are worth a look.