[ILUG] Out of Memory

[Smelly Pooh]

In reply to Paul Jakma's flatulent wordings, 
   
>   > a) a deadlocked machine (pre 2.2.14 linux)
>   
>   > or 
>   
>   > b) a machine where the OS has killed some of your processes -
>   > perhaps innocent and/or important ones.. (linux
>   > 2.2.14+/solaris/etc..)
>   
>   > neither option is nice.
>   
>   Are you really suggesting A) is not many, many times worse than B)?
> 
> Both are bad. Linux didn't do B up until recently, and then did it
> badly. 2.2.15 should be a lot better in that respect. (but it isn't
> out yet). Also, would you leave a box running after experiencing B)?
> 
> however... my point, again, there are ways to avoid OOM completely on
> both linux and the rest. And if the risk of OOM is unacceptable, you
> should safeguard against it. And the methods used are similar on both
> linux, solaris, freebsd...
> 
> ie:
> 
> C) minimise the risk of OOM all together if the cost of prevention is
> acceptable. (and remember this holds for BSD/solaris/SysVR4 too!!)

It does not change the fact that Linux does B) instead of A), when a
supposedly stable OS should do A) instead of B).  I've read both your
arguments and to be honest, instead of sidestepping toward a C) option which
can make just about any OS look like a perfect little memory manager maybe you
should just accept the fact that Linux is no good dealing with OOMs and stop
dragging on this thread with non-points and tangents.

>   Put it a different way around - if on every other modern unix, the
>   worst case scenario is processes start getting killed, but on Linux
>   the worst case is the box hardhangs, why the smeg is any sane person
>   armed with this knowledge use linux?
>   
> put it this way. Linux takes a lot more liberties with VM than other
> Unices. So if you can't afford OOM, then you need to take steps to
> avoid it. 

What steps are you proposing?  Your universal point C as cited above or some
magical hidden step that you like to allude to but not exactly tell anybody?
(i.e. one that doesn't exist?)

> i agree, linux kernel doesn't have the nice safety nets that solaris/freebsd
> do. it's not very friendly, i agree. but that's the way it is.

FreeBSD is as equally unfriendly as Linux, but please don't use the expression
"safety nets", it gives me the impression that Linux foregoes little gotcha
proofing a la undeletes in the FS and "do you really want to format your C:"
messages in the pursuit of "doing the right thing" which quite frankly is not
true in this case.  Handling OOMs gracefully is not a "safety net", it is an
integral part of memory management.

> With linux you set up the resource limits yourself, and
> you configure the amount of swap you want - and you need to know that
> this will determine linux's likelyhood to OOM. That's just an aspect
> of linux...

It's an aspect of just about every other modern Unix, not this unfriendly but
perfect if you get to know it beast we call Linux.  Resource limits only
handle the case where one process or one user goes out of control and tries to
bring the system down.  It does not handle any other situation that might
cause an OOM

> I agree, sol/bsd/etc are a bit more admin friendly in that respect.

Now you're giving me the impression that Linux does just the same thing as
sol/bsd/etc, just that it doesn't have a nice GUI to let us non-linux-gurus do
it easily, but given a competant Linux admin, the equivalent is just a config
file away.  That my friend is bullshit, there is a helluvalotta difference
between a Unix with an rlimit syscall (name one modern Unix without it) and a
kernel that can deal with OOMs elegantly.

> But they too will go OOM unless you take very costly precautions.

Here we have the abstract solution again, the point is not whether an OOM
situation will occur (I think we all know that yes it is possible for an OS
given limited memory to OOM when it runs out), you don't seem to be handling
the fact that Linux reacts badly to OOMs.

> Ie: with commercial unices there are extensive (and expensive) safety
> checks to try out guess the memory allocation behaviour of processes,
> and they are nowhere near perfect, and so you'll still have a partly
> hosed box if a process or processes go screwy in a funny way.

Are you saying that all commercial unices do this?  When you say "with
commercial unices" it doesn't look like you're saying one in particular or
even some.  I doubt that they "all" do it (nor was I aware that safety checks
were responsible for guessing memory allocation behaviour), even though I'd be
open to the possibility that a few do.  But I won't take your word for it,
please prove by URL.  What about lesser non-commercial unices like *BSDs that
do handle OOMs without numb nutting?  Do they do all these extensive (and
expensive) safety checks?  Because last I recall, FreeBSD and Linux didn't
differ too much in speed on a uni processor architecture (but evidently Linux
has finer grained kernel locking for SMP but you're not going to try play that
card on me are you?) but FreeBSD isn't known for dying on OOMs

> And with linux, there are few checks, cause there is no perfect
> heuristic to allow overcommit VM/ fork COW while not risking OOM.

As was mentioned before, the question is not whether an OOM will happen, it's
how the kernel deals with it when an OOM does happen.  You obviously believe
in OOMs, I believe in OOMs, Dave Murphy believes in OOMs, we're not arguing
you down and going, by god man snap out of it, there's no such thing as an
OOM!  We're not even arguing that Linux is the only OS that suffers from OOMs,
what people are talking about is the way Linux handles them

> So it leaves it up to the admin to set things up, cause it's assumed he
> knows a lot more about how the machine is to be used, what load it will
> experience, what app's it will run, what level of swap usage is affordable..
> etc..

Ah yes, at the end of the day, the sun is setting, the curtains are drawing to
a close. The wiley linux advocate sits back, smiles to himself satisfied in
the knowledge that once again, Linux has proven itself the better OS, not
because of any technical superiority of Linux itself, but because Joe
"Linux-Guru" Soap will set it up better or cheaper than Jill "M$ NT newbie"
Misinformed (sorry I'm no expert on surnames) or Bob "Commercial Unix"
Moneybags, and if by some miracle Joe couldn't make his hard sell because Bill
"I want a solution" consumer wants something Linux doesn't have, then Joe can
always mention Jimmy "the kernel hacker nextdoor" Freakshow who's working on
that exact feature right now.

> get it?

got it, but not the way you put it