A data import script went rogue last week and tried to load an entire dataset into memory in one go, on a box that also runs a couple of things I care about. The old version of this story ends with the OOM killer firing semi-randomly and reaping whichever process annoyed it least, possibly the one I needed. This version ended with the import dying alone and everything else carrying on, because the script runs as a systemd service and I'd given it a memory limit.
That's the whole win, and it's a cgroups v2 win. systemd puts every service in its own cgroup, and on a v2 system you can cap a unit's memory with one directive:
[Service]
MemoryMax=2G
MemoryHigh=1500M
MemoryHigh is the soft throttle: cross it and the kernel starts aggressively reclaiming and slowing the cgroup down. MemoryMax is the hard wall: cross that and this cgroup gets the OOM killer, not the rest of the machine. The runaway import hit 2G, got killed inside its own boundary, logged a clean failure, and the host never noticed.
The bit I appreciate is the blast radius. Without the limit, a memory leak anywhere is everyone's problem. With it, a leak is the leaking service's problem, and I find out from a failed unit and a journal entry rather than from the whole box going unresponsive. I've now gone through the units that do bulk work and given each one a sensible ceiling. It took ten minutes and it's the cheapest insurance I've bought all year.