James Olin Oden wrote:
On 3/1/07, Adam Gibson <agibson@xxxxxxx> wrote:
I prefer for my desktop system to have plenty of RAM. If swap is ever
filled up by even 64 megs something is wrong. By setting swap very low
and making sure I have plenty of memory if some app does start eating up
memory the oom killer will kill the task much faster if your system
isn't busy trying to swap 512 megs of running tasks that got pushed into
swap because of one runaway app.
The problem with the OOM killer is it cannot differentiate between
mission critical apps and other not so critical. Course, once you
really do run out of memory what other choice do you have? An
automatic orderly shutdown and reboot (that actually might be a better
choice for telco/CGL environments). Anyway just some thoughts...james
For a server I agree that it is a gamble... would you rather the system
eat itself alive and be non responsive requiring a hard reset or for it
to try and kill the app that it thinks is causing the problem though.
Either way there is a possibility of lost data but with the small swap
though you can restore things to working order quicker and safer imho.
I would argue that killing the app vs a hard reset is better in most
circumstances especially if you have more than one service running on
the server. Kill all services and make them get into an unknown state
because of a hard reset or just have one service get that treatment. I
vote for the latter. I never set more than 256 megs of swap on servers
but even with that much swap the system can stay non-responsive for a
very long time if the system gets overloaded memory wise.
For a desktop system though the oom killer seems to kill the correct app
for me because I have plenty of memory to spare so it kills the one with
the most memory I assume. It might get it wrong but you should save
often anyway. This is not as critical for a desktop system for the oom
killer to try and kill something.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
