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

[Les Mikesell]

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