User: Password:
Subscribe / Log in / New account

Taming the OOM killer

Taming the OOM killer

Posted Feb 5, 2009 10:23 UTC (Thu) by epa (subscriber, #39769)
In reply to: Taming the OOM killer by dlang
Parent article: Taming the OOM killer

The current setup (where memory is overcommitted and there is an OOM killer) is also quite capable of slowing the system to an unusable crawl if you have swap space in use. So I don't think that turning off overcommit and allocating a slightly larger amount of swap would make the situation any worse.

(On a related note, the kernel is free to refuse any request for extra memory, and can do so for its own reasons. So for example if a process needs to fork() then the memory allocation would normally succeed, on the assumption that the extra memory probably won't be used, but provided there is enough swap space to back it up just in case. Whereas an explicit memory allocation 'I want ten gigabytes' could, as a matter of policy, be denied if the system doesn't have that much physical RAM.)

(Log in to post comments)

Taming the OOM killer

Posted Feb 5, 2009 21:03 UTC (Thu) by dlang (subscriber, #313) [Link]

I'm not talking about 'I need 10G of memory' allocations, I'm talking about cases where lots of small programs end up using individually small amounts of memory, but the total is large.

but if you have large programs that may need to fork, it's not nessasarily the case that it's 'a slightly larger amount of swap'. I've seen people arguing your point of view toss off that a large system should be willing to dedicate a full 1TB drive just to swap so that it can turn overcommit off. in practice, if you end up using more than a gig or so of swap your system slows to a crawl

Taming the OOM killer

Posted Feb 5, 2009 22:26 UTC (Thu) by epa (subscriber, #39769) [Link]

I think it would be useful to add swap space for 'emergency only' use. So if all physical RAM is free, the kernel starts refusing user space requests for more memory. However if a process wants to fork() the kernel can let it succeed, knowing that in the worst case there is swap space to back its promises.

It is rather a problem that merely adding swap space as available means it can then be used by applications just as willingly as physical RAM. Perhaps a per-process policy flag would say whether an app can have its memory allocation requests start going to swap (as opposed to getting 0 from malloc() when physical RAM is exhausted). Then sysadmins could switch this flag on for particular processes that need it.

Taming the OOM killer

Posted Feb 6, 2009 0:45 UTC (Fri) by nix (subscriber, #2304) [Link]

The problem is that the system is more dynamic than that. Swap space is
moved to and from physical memory on demand; there is almost never much
free physical memory, because free memory is wasted memory, so the first
sign you get that you're about to run out of memory is when you're out of
*swap* and still allocating more (reducing the various caches and paging
text pages out as you go).

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds