Optimization

If you search “reduce Linux RAM usage”, what you mostly find is lists of sysctls to paste — set swappiness to this, drop the caches, disable that. I’ve never seen that approach survive contact with a real production host. What works is much less glamorous: a measure-change-verify cycle, applied in the right order — shrink the application working set first, isolate services second, compress third, and buy RAM only when the numbers prove nothing else will do. ...

The first time I priced out a memory upgrade this year, I assumed the listing was wrong. It wasn’t. DRAM contract prices are now more than four times what they were in the third quarter of 2025, and suddenly a question that used to be a no-brainer — “should I just add RAM?” — is worth actual engineering time again. That’s what this series is about. For years, throwing memory at the problem was the rational move: RAM was cheap, engineer hours weren’t. In 2026 that math has flipped, and before spending money at these prices you want to know whether the constraint is real memory pressure, reclaimable cache that only looks like consumption, or one process that nobody has looked at in months. This first part builds that answer — a reliable baseline. Part 2 configures swap, zram and zswap , part 3 contains services with cgroups , and part 4 puts it all together into a plan and a buy-or-optimize decision . ...