[rt-users] FastCGI vs/or FastCGId? System memory "leak"?

Les Mikesell les at futuresource.com
Mon Feb 6 14:48:33 EST 2006

On Mon, 2006-02-06 at 12:54, Justin Zygmont wrote:
> > 
> > When something works there's not much need to be maintained. I
> > haven't had any problems that I'd blame on fastcgi after installing
> > according to:
> > http://wiki.bestpractical.com/index.cgi?RHEL4InstallGuide
> > 
> > The one thing that might be different between mod_perl and
> > fastcgi is that apache has a directive for how many pages
> > to let a child process serve before killing it and starting
> > a new one that work with mod_perl processes.  You can use this
> > to balance between speed and memory leaks by forcing the
> > perl processes to restart regularly. I don't think fastcgi
> > has a similar option, although if the program exited on its
> > own it should restart a new one.  Is there any RT option to
> > say that if it is consuming some amount of memory and has served
> > some number of pages that it should die at the end of a request?
> If it has a memory leak, there's a reason to maintain the code, it hasnt 
> been changed since 2003, which is why some of us are thinking it may no 
> longer be maintained.

The memory leak probably isn't in fastcgi itself. It is just a
framework to start as many instances of some perl program as
you tell it and keep them running.

> Is that MaxRequestsPerChild ?  such a setting for fastcgi could provide 
> a way to control the problem.  Just watch the memory usage for your fcgi 
> processes, as long as you dont restart apache, you'll se them slowly get 
> bigger and bigger.

Yes, apache uses MaxRequestsPerChild to kill the process regardless
of the language extension and I don't think there is an equivalent
for fastcgi.  However, note that if you kill one of the running
mason_handler.fcgi processes, it will start a new one, so if that
program could be modified to exit gracefully at appropriate times
things would take care of themselves.

  Les Mikesell
   les at futuresource.com

More information about the rt-users mailing list