Taming the OOM killer
Posted Feb 8, 2009 19:05 UTC (Sun) by anton
In reply to: Taming the OOM killer
Parent article: Taming the OOM killer
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
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
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).
to post comments)