Recent Features
| |||||||||||||
Taming the OOM killerTaming the OOM killerPosted Feb 8, 2009 19:05 UTC (Sun) by anton (guest, #25547)In reply to: Taming the OOM killer by cpeterso 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
(i.e., 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).
(Log in to post comments)
|
|||||||||||||