[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: non-automated test failure report! :)
On Wed, Nov 16, 2011 at 08:34:08PM +0000, Michael van Elst wrote:
> >Not really, no. In most ordinary overload cases, it will grind to a
> >halt swapping long before it actually OOMs.
> I see OOMs a lot on Linux and hardly any of these follow
> heavy swapping. Mostly it is a heavily loaded system and
> something suddenly touching non-allocated memory
> it never should have been granted.
Blah... that I haven't seen actually, but I don't have or use any
heavily loaded Linux systems any more.
> >Like I said, it would perhaps be desirable to have a switch for
> >pessmistic swap allocation. But there's no real reason to turn it on
> >in practice.
> Stability is a reason. But in Linux not even disabling
> overcommittment and having swap larger than RAM helps to
> eliminate the OOM killer.
That seems odd. With overcommit turned off it shouldn't ever OOM.
>> The "random" part is where you're going off the rails.
> It is still "random" to some degree, used to be worse.
Ours is not; if you have a runaway process it's just about always the
one that gets killed. Once in a while it kills the X server instead
though, because the X server is a large process that sometimes eats a
lot of memory. However, it almost invariably follows up on this by
killing syslogd, which is pretty poor.
(As best I can tell this is because it logs that it's going to do the
kill before or as it does it; this wakes up syslogd, syslogd goes into
the kernel to handle the message, tries to allocate kernel memory,
fails, and then becomes another victim.)
David A. Holland
Main Index |
Thread Index |