RAM

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. ...

Everyone who has run Linux servers for a while has lived through some version of this incident: one service — a leaky app, a batch job, a runaway query — grows until the whole host starts thrashing, and by the time the OOM killer wakes up, it kills something you cared about more than the actual culprit. The zram and zswap work from part 2 protects you from peaks, but it does nothing against this. Compression buys headroom; it doesn’t assign blame. ...

In part 1 of this series I made the case for measuring memory pressure before spending money on RAM that now costs more than four times what it did a year ago. If your measurements showed short, compressible peaks — cold pages sitting around while the active working set fits fine — this is the post where compression earns its keep. I want to be upfront about one thing, because “just enable zram” has become the reflexive advice in every forum thread about low memory: zram and zswap do not create free memory. They spend CPU cycles compressing pages you are not actively using. When the data compresses well and the CPU has headroom, that trade is excellent. When it doesn’t, you’ve added a layer of complexity and gained nothing. So the goal here is not to enable everything — it’s to pick one mechanism deliberately and prove it helps. ...

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 . ...