On Tue, 7 Mar 2000, David Murphy wrote:
Quoting <Pine.LNX.4.21.0003062102090.12018-100000 at hibernia.spin.ie>
by Paul Jakma <paul at clubi.ie>:
If you don't have enough memory, you don't have enough, and that's a
hardware configuration issue no OS is going to solve. However, an OS
can be more or less good at dealing with the situation. In my
experience, Solaris and FreeBSD don't lock up, Linux does.
granted. but there are easy steps you can take to avoid it.
Your
experience may well vary - the only way to get beyond "Well, FooOS
never locked up on me" is sit everyone down in one room and let them
see it in person.
> 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!!)
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.
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. 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...
I agree, sol/bsd/etc are a bit more admin friendly in that
respect. But they too will go OOM unless you take very costly
precautions.
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. And so
you still need to add lot's of swap, resource limits, etc.. possibly
even disable demand paging, and go back to backing store swap model,
if you want to be sure you never end up OOM. (and so what did that
expensive kernel VM beancounting buy you?)
And with linux, there are few checks, cause there is no perfect
heuristic to allow overcommit VM/ fork COW while not risking OOM. 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..
get it?
--
Paul Jakma paul at clubi.ie
PGP5 key: http://www.clubi.ie/jakma/publickey.txt
-------------------------------------------
Fortune:
The only difference between a car salesman and a computer salesman is
that the car salesman knows he's lying.
Maintained by the ILUG website team. The aim of Linux.ie is to
support and help commercial and private users of Linux in Ireland. You can
display ILUG news in your own webpages, read backend
information to find out how. Networking services kindly provided by HEAnet, server kindly donated by
Dell. Linux is a trademark of Linus Torvalds,
used with permission. No penguins were harmed in the production or maintenance
of this highly praised website. Looking for the
Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!