Re: FastCGI Expert Sought

On Thu, Jul 16, 2009 at 11:04 PM, Ross Richey<[email protected]> wrote:
> Several people have suggested that PERL is the problem.  And indeed in a
> sense it is.  It's really hard to keep PERL from leaking memory, so hard
> it's not worth even trying.

Perl doesn't usually leak, at least not in the sense that C programs
do.  It doesn't have pointer problems and lose track of memory.  It
will typically grow over time though, as your program uses more memory
for data, and it keeps the memory it allocates as a speed optimization
for the next time you use the same variable.  The common solution to
this in mod_perl-land is to check the size of the process at the end
of requests and kill the process if it gets too big.  Then apache
spawns a new one.

> So yes this might be something which needs to be handled at the Lighttpd
> level.  But before we do that I just want to ask the conceptual question:
>
> Is there some method of nicely killing and respawning a FastCGI process?
>
> The reason I asked for an expert and offered money is that we're fully
> expecting that we might have to get someone to actually add that
> functionality to FastCGI, but obviously I'm open to other ideas on fixing
> the problem.

I'm no FastCGI expert, but I think you're missing the fact that
FastCGI is a protocol, not a piece of code.  The code you run that
implements FastCGI for Lighttpd is strictly a Lighttpd thing, and it
can implement process management in any way it chooses.  That's why I
suggested you talk to them.

- Perrin