“At that point, things can grind to a painful halt, with the
only possible solution (other than rebooting the system) being to
kill off processes until a sufficient amount of memory is freed up.
That grim task falls to the out-of-memory (OOM) killer. Anybody who
has ever had the OOM killer unleashed on a system knows that it
does not always pick the best processes to kill, so it is not
surprising that making the OOM killer smarter is a recurring theme
in Linux virtual memory development.“Before looking at the latest attempt to improve the OOM killer,
it is worth mentioning that it is possible to configure a Linux
system in a way which all but guarantees that the OOM killer will
never make an appearance. OOM situations are caused by the kernel’s
willingness to overcommit memory. As a general rule, processes only
use a portion of the address space they have allocated, so limiting
allocations to the total amount of RAM and swap space on the system
would lead to underutilization of system memory. But that
limitation can be imposed on systems which can never be allowed to
go into an OOM state; simply set the vm.overcommit_memory sysctl
knob to 2. Individual processes are much more likely to see
allocation failures in this mode, but the system as a whole will
not overcommit its resources.“Most systems will allow overcommitted memory, though, because
the alternative is too limiting. Overcommit works almost always,
but the threat of a day when the Firefox developers add one memory
leak too many always looms.”