[ILUG] Out of Memory

[Paul Jakma]

On Tue, 7 Mar 2000, Smelly Pooh wrote:


> It does not change the fact that Linux does B) instead of A),

i've never disputed this. i've never argued A (deadlock) was better than
B (post OOM killing, etc..)

>  when a
> supposedly stable OS should do A) instead of B).  

if you get to the stage where you need B, then you are unstable
already. 

a *configuration* where stability was the goal would not use overcommit
at all!!!!! 

(that rules out linux by the way. you can't disable overcommit)

> 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.

at no point did i say that linux's OOM behaviour was good. You've missed
the entire thrust of my arguments because you incorrectly assumed that i
was advocating linux. 

(blind OS advocay is bad... be it linux, T64, solaris...)

> 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?)
> 

it depends on the specific Unix. Tru64 can be configured to use backing
store rather demand paged swap, and there's various kernel variables to
tinker with too. (i don't know much about t64 kernel variables)

 Solaris has a 'hard' memory config i've heard which achieves the same.
IRIX also has options to disable overcommit.

linux can not disable overcommit. (which is not neccessarily a bad
thing)

> 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.
> 

no it's not. Killing processes is a horrible kludge because of the
inescapable fact that no VM today that does overcommit is clever enough
to be able to avoid OOM.

however until the VM gurus find that magic VM, i will accept that
linux's OOM behaviour is far worse than that of other unix's. Although i
do not neccesarily accept that other Unices behave better than linux
under heavy VM pressure.

(show me the proof)

> 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 remember hanging a solaris 2.4 box by filling up tempfs. does that
still work? Anyway, back to point, whatever way you handle OOM doesn't
matter really, cause it's too late.

there are many many ways to kill a unix machine.

> it easily, but given a competant Linux admin, the equivalent is just a config
> file away.  That my friend is bullshit, 

indeed it is. of course it's not a matter of just one config file. it's
a matter of knowing that linux will bite you a lot harder than other
kernels if you allow the box to OOM.

> 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),

actually, it is quite possible for a Unix to guarantee that it will
never OOM, even with limited memory. (linux can't do this).


> 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.

i don't know solaris, but tru64 can do extensive bean-counting, ie it
will keep track of everything if you want it to. (and you better have
huge amounts of swap to store all this accounting info). I guess solaris
can do the same. 

>  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?

you're confusing bean-counting with OOM handling. Two different
things. the beancounting is there to prevent OOM, but it slows down
process creation/tear down, it needs more RAM/swap to store accounting
info.

the oom handling code decides which processes to kill. should be rarely
used, and linux has this aswell. (though not very good).


> card on me are you?) but FreeBSD isn't known for dying on OOMs
> 

i've no idea about freebsd. if it doesn't do beancounting but does do
better OOM. So what?

> 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
> 

i'm more of the opinion that the OOM risk is a compromise between VM
heaviness/speed and operational stability. That compromise will differ
between a desktop, web server, important transaction server. What's good
for desktop, web server is not neccesarily good for the big important
ERP machine..

you starting to see where i'm coming from? 

I'm not advocating "use linux everywhere because it is the one true OS".
I'm saying, look these are the issues, these are the design compromises
in xyz, don't disregard AcmeOS because of xyz, because xyz is there for
a reason, and xyz might even be an advantage...

I'm advocating awareness.

> 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.
> 

Joe Soap, Jill Misinformed and Bob Moneybags!! LOL. That sounds like a
real good idea for a web cartooon!!!

:)

> > get it?
> 
> got it, but not the way you put it
> 

-paul

[who hopefully won't have to write too much more about OOM]
:)