Hacker News Reader

Comment by vectorEQ | Hacker News Reader

what if an application contains a memory leak. it could hypothetically use up your infinite ram, and linux will then start randomly killing stuff to try and recover.... adding swap allows you to trigger on memory issues / overload without random shit getting killed. you could then kill the offending process yourself specifically being triggered by some memory usage monitor or w/e instead of running the risk of other critical processes being killed.

View on HN

Well to start, slap default resource limits on your processes so they can't use all the RAM in the world. Then your leaky processes will crash when their mallocs fail and everyone will be as happy as they deserve.

I agree with the idea, but a nit: on 64-bit Linux with the default vm.overcommit_memory=0, their mallocs will likely continue to succeed. Those just expand the address space, which is probably not what your resource limits are controlling. [1] The actual limit [2] is hit when they try to use the virtual address space, causing a minor page fault (when it's backed by a zero-filled page of physical RAM).

[1] You can add in such a limit via RLIMIT_AS, but it'd have a lot of collateral damage like preventing LMDB from mmap()ing a big database. I don't recommend this.

[2] I'd recommend setting limits on a cgroup; with a systemd unit file, see MemoryMax= and friends in the systemd.resource-control(5) manpage.

mallocs never fails. By design. That's the whole point of all this.

On Linux you can make them fail, but don't do that unless you know what you're doing.

Why do you need to wait for it to swap to trigger a memory usage alert?

Reply on news.ycombinator.com