On Thu, 2006-06-01 at 19:18 -0400, Sam Drinkard wrote: > Johnny, > > After reading about the VM issue, I concur. The previous kernel did > exhibit the behavior noted in the URL you sent. Looking right now, I > see a considerable difference in use / swap. The software running on > the machine generally uses anwhere from 1.2 > 1.4Gb of memory, and I had > noticed swap would, over time, increase, while there was still *some* > memory available, but it never would use totally all of it. The > application running right now is a little different from the one that > runs late-night and after 16z, so I'll take a peek at it either tonight > if I'm up or in the a.m. after the thing starts. I'll also note swap > and its size as time progresses to see if it increases as before with > free mem. I forget the start of this thread... was 64 bit only? Anyway, I had my 32bit lock a couple times with symptoms like Sam mentions. Lots of swap used and no reason for it. Was using lots of open browsers, a couple different GUI MUAs, etc. Turned off things I didn't need for this workstation behind firewall on cable, like sendmail, spamc/d (started by evolution as it needs regardless of system started), etc. A *biggie*, maybe, is the stupid readahead and readahead_early stuff. Take a look at their file lists. Some small % suits your needs, the rest is just someone's idea of every possible thing that might speed up initial response. I completely disable these and have seen no difference. As I expected, after initial boot, most of it is wasted and the "non-manual" memory management does a better job than someone who probably got told "Make our boot faster than Windoze". Up now for 6 days running similar load (I think, haven't bothered to really measure it) and swap use is still good and response is still good. I suspect the heavy duty servers a lot of you have can also live without these readahead* things. Put a stopwatch on it and see. YMMV. > > Thanks for the info. > HTH -- Bill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.centos.org/pipermail/centos/attachments/20060601/a4c5a574/attachment-0004.sig>