Making sense of OOM killer messages?

[Naoki]

I agree with the BSD folks that there is no way to fairly decide which
process should be killed.  However I'd _much_ rather have a system come
back missing a process than a halted box.

The question though is how to diagnose the cause of the memory issue.

If OOM doesn't give any information about process state before it starts
killing then it's hard to track down the root cause.


On Tue, 2005-11-29 at 15:53 +1100, Steffen Kluge wrote:
> On Mon, 2005-11-28 at 21:09 +0800, John Summerfied wrote:
> > I'm not sure it's useful to know that:-( In my experience (which 
> > includes 2.6 kernels that are supposed to do this better) the killed 
> > process is generally an innocent bystander.
> 
> The process that triggered the OOM condition is probably just as
> innocent. There isn't always a "cuplrit", and if there is it isn't easy
> to spot. The OOM killer tries to do the most sensible thing by killing
> less active processes that still yield a fair amount of released memory.
> 
> BTW, the OpenBSD folks reckon there is no reasonable or fair way of
> dealing with an OOM situation and take the easy way out: they simply
> halt the whole system...