> > I'm looking for some help getting apache to run reliably. Apache 1.3.9
with
> > mod_perl 1.21 and Perl 5.005_03 is running on a dual P500 with 1 Gb of
RAM
> > running Redhat 6.1. We run about 5 sites off the box, most of which are
> > fairly high traffic, and use a lot of CGI and
> > MySQL 3.22.25 is used with Apache::DBI.
> >
> > The major problem seems to be a memory leak of some sort, identical to
that
> > described in the "memory leak in mod_perl" thread on this list from
October
> > 1997 and the "httpd, mod_perl and memory consumption (long)" thread from
> > July 1997.
>
> [snip]
>
> I too have had this problem and haven't found a suitable solution. In
> my case, though, I think the leaks are primarily do to old perl
> scripts being run under Registry and not bugs in mod_perl or perl.
Well as I said, there is a lot of old code, which I guess could be the
culprit.
> The first thing to do is to try to discover if the problem is a
> mod_perl problem or a bad script problem. If your server can handle
> it, you could try a binary search to find which (if any) scripts make
> the problem worse. Basically pick half your registry scripts and use
> mod_cgi. If leaks persist, you know that you have some problem
> scripts in the ones you didn't make mod_cgi. If leaks stop, then you
> know the problem scripts are in the ones you made mod_cgi. Repeat as
> necessary until you have narrowed it down to a single script. This is
> tedious though and may not be practical.
Ok, i'll try this when I get time.
> Now, let's assume the problem is in fact in mod_perl or apache or perl
> itself. In this case I'm not sure what the best way to proceed is. I
> think mod_perl and perl have shown themselves to be pretty good about
> not leaking memory, as has apache. IMO it's much, much more likely a
> problem concerning Registry and impolite scripts that are misbehaving
> and leaving parts of themselves around.
Yeah, i'm willing to believe my scripts could be a cause.
> Have you tried correlating the memory surges with any page accesses?
> That may help narrow down the culprit.
I'm not really sure how I could go about doing that, any suggestions? :)
--
James Furness <[EMAIL PROTECTED]>
ICQ #: 4663650
