{"id":1613,"date":"2026-11-05T22:40:31","date_gmt":"2026-11-05T22:40:31","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=1613"},"modified":"2026-11-05T22:40:31","modified_gmt":"2026-11-05T22:40:31","slug":"cgroup-v2-memory-high-watermark-protection-tuning","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/cgroup-v2-memory-high-watermark-protection-tuning\/","title":{"rendered":"cgroup v2 Memory High and Watermark Protection: Tuning Real Workloads on a VPS"},"content":{"rendered":"
\n

Most guides treat cgroup memory control as one knob: set memory.max<\/code> and let the OOM killer sort it out. cgroup v2 exposes four controls with different semantics, and the most valuable \u2014 memory.high<\/code> \u2014 kills nothing. It throttles the cgroup into direct reclaim, forcing it to give back page cache, and escalates only if the cgroup cannot comply. On a 2-4 GB VPS running three or four services, that is the difference between one slow service and the whole machine dying.<\/p>\n

The four memory controls and what each enforces<\/h2>\n

cgroup v2 memory controller files live in the cgroup directory, typically \/sys\/fs\/cgroup\/<unit>\/<\/code> under systemd. Each has distinct behaviour:<\/p>\n\n\n\n\n\n\n
File<\/th>\nSemantics<\/th>\nConsequence<\/th>\n<\/tr>\n
memory.max<\/td>\nHard limit on total charge (anon + page cache + kernel)<\/td>\nReclaim attempted; OOM kill on failure<\/td>\n<\/tr>\n
memory.high<\/td>\nThrottle threshold<\/td>\nDirect reclaim, slowed allocations, no kill<\/td>\n<\/tr>\n
memory.low<\/td>\nBest-effort protection from global reclaim<\/td>\nBias only; not a reservation, can be overridden<\/td>\n<\/tr>\n
memory.min<\/td>\nHard protection from reclaim<\/td>\nPages are never reclaimed while the cgroup exists<\/td>\n<\/tr>\n<\/table>\n

memory.max<\/code> is the wall, memory.high<\/code> the speed bump before it, memory.low<\/code> a suggestion to the reclaim algorithm, and memory.min<\/code> a real reservation. Most incidents on small VPS instances come from setting only memory.max<\/code> and never reclaiming the 400 MB of cache the application was holding.<\/p>\n

How throttling actually happens under memory.high<\/h2>\n

When a cgroup’s charge crosses memory.high<\/code>, each subsequent allocation must trigger reclaim proportional to how far over it is. The kernel does not run the OOM killer; it makes the allocating task reclaim synchronously, so the application stalls inside malloc<\/code> or a page fault. Reclaim order matters: clean page cache first, then dirty pages written back and dropped, then file-backed executable pages, then anonymous pages pushed to swap. If swap is unavailable \u2014 common on small plans \u2014 anonymous memory cannot be reclaimed and the cgroup can only shrink its cache. Once there is nothing left, the next allocation hits memory.max<\/code>.<\/p>\n

\ncat \/sys\/fs\/cgroup\/myservice\/memory.current\ncat \/sys\/fs\/cgroup\/myservice\/memory.high\ncat \/sys\/fs\/cgroup\/myservice\/memory.events\n# memory.events shows: low high max oom oom_kill oom_group_kill\n<\/pre>\n
memory.events<\/code> is the audit trail. Rising high<\/code> with stable oom_kill<\/code> means throttling works. max<\/code> incrementing means you hit the wall and reclaim failed; oom_kill<\/code> incrementing means something died.<\/p>\n
Page cache reclaim is the point, not a side effect<\/h2>\n
On a 2 GB box, a Node.js or Java service that reads many files accumulates hundreds of megabytes of page cache. That cache counts in memory.current<\/code> but is free memory \u2014 dropping it costs a re-read. Setting memory.high<\/code> at 85-90 percent of memory.max<\/code> makes the service eat its own cache before the system comes under pressure.<\/p>\n
Without memory.high<\/code>, global pressure reclaims proportionally across cgroups, so your database’s hot pages get dropped to make room for a build job. memory.low<\/code> biases reclaim away from the database but only as a weight; memory.min<\/code> is the only guarantee.<\/p>\n
\n# systemd drop-in for a 2 GB box, service capped at 1.2 GB\n[Service]\nMemoryMax=1200M\nMemoryHigh=1000M\nMemoryLow=400M\nMemorySwapMax=0\n<\/pre>\n
Apply with systemctl daemon-reload<\/code> and verify with systemctl show myservice -p MemoryMax -p MemoryHigh<\/code>; cat memory.high<\/code> should return 1048576000 for 1000M.<\/p>\n
Practical thresholds for a 2-4 GB VPS<\/h2>\n
Start from resident working sets, not total RAM. Measure each service’s RSS under realistic load with smem -tk<\/code>, then add 15-25 percent for fragmentation and transient buffers.<\/p>\n