{"id":1300,"date":"2026-10-05T03:05:54","date_gmt":"2026-10-05T03:05:54","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=1300"},"modified":"2026-10-05T03:05:54","modified_gmt":"2026-10-05T03:05:54","slug":"tuning-vfs-cache-pressure-dentry-inode-small-vps","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/tuning-vfs-cache-pressure-dentry-inode-small-vps\/","title":{"rendered":"Tuning Linux File Cache Pressure (vm.vfs_cache_pressure) on a VPS"},"content":{"rendered":"
\n\n

vm.vfs_cache_pressure<\/code> controls how aggressively the kernel reclaims dentry<\/em> and inode<\/em> 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.<\/p>\n\n\n\n

What the parameter really does<\/h2>\n\n\n\n

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<\/em> 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.<\/p>\n\n\n\n

# current value and where it lives\nsysctl vm.vfs_cache_pressure\ncat \/proc\/sys\/vm\/vfs_cache_pressure\n\n# persistent drop-in (recommended over editing sysctl.conf)\ncat >\/etc\/sysctl.d\/60-vfs-cache.conf <<'EOF'\nvm.vfs_cache_pressure=50\nEOF\nsysctl --system<\/code><\/pre>\n\n\n\n
Watch the slabs<\/h2>\n\n\n\n
Dentries and inodes are exposed via slabinfo. Track dentry<\/code> and ext4_inode_cache<\/code> (or the btrfs equivalents) over time:<\/p>\n\n\n\n
# object counts and memory per cache\ngrep -E 'dentry|inode_cache' \/proc\/slabinfo | awk '{print $1,$2,$3,$4*$5\/1024\" KB\"}'\n\n# total reclaimable slab memory\ncat \/proc\/meminfo | grep -E 'Slab|SReclaimable|SUnreclaim'<\/code><\/pre>\n\n\n\n
On a host serving thousands of small files, a healthy configuration shows dentry<\/code> and inode slabs growing to a stable plateau and SReclaimable<\/code> accounting for most of the slab. If SUnreclaim<\/code> dominates, you have a kernel leak, not a cache-pressure problem — lowering pressure will not help, and you must not raise it.<\/p>\n\n\n\n
Value<\/th>Behaviour<\/th>Best for<\/th><\/tr><\/thead>
50<\/td>Keeps dentries\/inodes longer<\/td>Many small files, WordPress, git, containers<\/td><\/tr>
100<\/td>Default proportional balance<\/td>General purpose<\/td><\/tr>
200–500<\/td>Evicts metadata eagerly<\/td>Large-file streaming, NFS client<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Measure the effect, don’t guess<\/h2>\n\n\n\n
Use a filesystem-walk benchmark that stresses the dentry cache, then compare at different pressure values. Drop caches between runs so each starts cold:<\/p>\n\n\n\n
# cold-cache directory traversal\necho 3 > \/proc\/sys\/vm\/drop_caches\n\/usr\/bin\/time -v find \/var\/www -type f -printf '' 2>&1 | grep -E 'wall clock|Minor'\n\n# stat every file, forces inode lookups\nfind \/var\/www -type f -exec stat -c '%i %s' {} + >\/dev\/null\n\n# repeat with the other value\nsysctl -w vm.vfs_cache_pressure=200<\/code><\/pre>\n\n\n\n
On typical web workloads the difference is real but modest: a warm dentry cache can cut find<\/code> 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<\/em> help when the working set exceeds memory — then you are simply trading page cache for metadata and may slow file reads.<\/p>\n\n\n\n
Interaction with swappiness and dirty ratios<\/h2>\n\n\n\n