Happy Friday! > The one way I know about to reliably prevent these problems is to use > syctl to change the value of vm.overcommit_ratio, and possibly adapt > vm.overcommit_memory. Both are documented in proc(5).
Ok, if time may look into it, but we were wishing there were "sensible defaults" set, out of the box so to speak. > By any chance, were your SL4 systems mostly 32-bit, and your SL5 systems > are mostly 64-bit? Confirmed. I noted the difference btw SL4 doing something sort of reasonable & SL5 not. > There's always GRSec and the like if you would like to run a modified > kernel.** Absolutely not but thank you anyway. > Having sufficient swap space does help. ... > Users just turn off the box if it goes unresponsive for more than a few > minutes, which is what happens when you have lots of swap allocated and > it starts paging itself to death. Server has 16GB RAM & 20GB swap; problem is, it's a compute server used by many. So one user (later mortified & remorseful, but) causes grief for many. And a forced reset is always a concern re: possible filesystem corruption. Thank you all very much for enlightenment + advice.
