[Cialug] Mitigating runaway swap with a vm.conf tweak?

[Josh More]

It's a reasonable idea, but I am always wary of tuning to avoid problems
as opposed to tuning for performance.  Performance is a discrete and
measurable goal.  While there are not an infinite number of problems you
could have, the number is certainly larger than the performance metrics.

It's analogous to using whitelists as opposed to blacklists.

A well tuned and coded system should never need be backfilled this way. 
However, if this were approached from a "I hope we never encounter this
type of situation, but in case we do, let's do this", it's analogous to
a defense in depth strategy, so I guess it makes sense.

However, I'd rather see a solution that runs risky applications in a way
that limits their resources (performance tuning, virtualization, chroot,
monit, etc).  That seems to be better design.



-Josh More, RHCE, CISSP, NCLP, GIAC 
 morej at alliancetechnologies.net 
 515-245-7701

>>> "Nathan Stien" <nathanism at gmail.com> 09/05/08 1:30 PM >>>
Howdy Luggers,

I happened upon a blog post that talks about changing a couple of
settings in /etc/sysctl.d/vm.conf to get better behavior when you have
a runaway process grabbing all of your RAM, making your machine
unresponsive:

https://www.joachim-breitner.de/blog/archives/303-vm.overcommit_memory-2,-vm.overcommit_ratio-0.html

He sets his overcommit ratio to zero, in order to "make sure that it
only hands out (swap size + 0 * RAM size) to processes," with the
proviso that your swap size approximates your physical RAM size.  The
idea is that you can still get the benefits of swap (little-used pages
get swapped out so the OS can use that physical memory for file
buffers), without a buggy program being able to malloc() your box to
death.

I wanted to poll the collective wisdom of the LUG to get some opinions
on the idea.  The author himself is also looking for better ways to do
this.

I anticipate some of you will just say "don't use swap!", but I prefer
to have swap on a desktop/laptop system.  (I am less attached to it on
servers.)

- Nathan
_______________________________________________
Cialug mailing list
Cialug at cialug.org
http://cialug.org/mailman/listinfo/cialug