Re: [cobalt-developers] RaQ3 memory leak problems?

[Jeff Lasman <jblists@xxxxxxxxxxxxx>]

Michael Stauber wrote:

> The SUN/Cobalt RaQ forum also has a lengthy and older topic on that issue with
> +40 replies, but a resolution in form of a patch does not appear to be in
> sight.

Yes; I searched that thread before I started this new one.  I'd hoped
there was a fix by now, but obviously there isn't <frown>.

> My resolution was a migration of all sites to a RaQ4R with 512MB and *without*
> that faulty GLIBC patch but even that didn't help. That box is as well
> bleeding memory and needs a reboot every two or three days. The longest time
> it stayed up in a row was two weeks, but then it crashed so badly that only a
> hard reboot brought it back.

This is a customer-owned system, and I fear he won't agree to buy a new
server just because an official patch has made his old one unusable
<frown>.

And of course if he does switch to a RaQ4 and we don't install that
particular patch, then as soon as there's an inclusive version number
upgrade it'll get installed anyway, or the upgrade won't work <frown>.

Our resolution will probably be to reboot the system with a cron-script
at 6:00 am every morning.  Does that sound reasonable to you?


> Having many dynamic processes which spawn and end childs to handle requests
> (Apache, MySQL and ASP) seems to worsen the problem dramatically. When a
> child dies apparently not all previously used memory of it is returned to the
> system for re-usage. A few bytes remain unusable and the number of unusable
> bytes increases with each dying process.
> 
> I have MRTG set up to monitor memory usage on my boxes and it has generated a
> set of nice graphics which tell the story in all its gory details:

In our case the problem was sendmail and a huge mailing list, but
nevertheless it worked fine until the nightly cron.daily scripts are
run.  Everything still works after the cron jobs finish, but memory
space keeps going down, and eventually email just stops working; I'm
sure if we waited long enough the system would crash.  Based on
experiences of the past few days it looks like rebooting at 6:00 am will
work for us.

> I'd bet money on MySQL being the most memory degrading application here,

For us it appears to be email in concert with something in cron.daily.

Let me know, please, what you think of my reboot scheme.

Do you thinking upping this 256 Megabyte box to 512 will help?

Thanks.

Jeff
-- 
Jeff Lasman <jblists@xxxxxxxxxxxxx>
Linux and Cobalt/Sun/RaQ Consulting
nobaloney.net, P. O. Box 52672, Riverside, CA  92517
voice: +1 909 778-9980  *  fax: +1 909 548-9484