Taming the OOM killer

Posted Feb 8, 2009 19:05 UTC (Sun) by anton (subscriber, #25547) [Link]

Once the OOM Killer starts shooting down processes, I can't imagine that system will remain in a usable state much longer.

I have actually experienced several times that the system was stable and usable after the OOM killer had killed the right process. This typically involved killing only a pure user program that was not needed for any system job. In several cases these were compiler runs on a machine with 24GB of RAM and 48GB of swap, and buying more memory was not very practical, and probably would not have helped anyway: the memory consumption was probably due to a bug in the compiler.

Concerning memory overcommitment, I think that this is a good idea for most programs (which are not written to survive failing memory allocations). And relying on overcommitment can simplify programming: e.g., allocate a big chunk and put your growing structure there instead of reallocating all the time. And when you do it, do it right (i.e., echo 1 >/proc/sys/vm/overcommit_memory), not the half-hearted Linux default, which gives us the disadvantages of overcommitment (i.e., the OOM killer) combined with the disadvantages of no overcommitment (unpredictable allocation failures).

Concerning critical system programs, those should be written to survive failing memory allocations, should get really-committed memory if the allocation succeeds, and consequently should not be OOM-killed.

I have outlined this idea in more depth, and I think that AIX and/or Solaris implement something similar. Instead of my per-process idea, the MAP_NORESERVE flag allows to switch between commitment and overcommitment on a per-allocation basis (not sure how useful that is, as well as the default of committing memory).