Re: Issued with Apache+mod_fastcgi+PHP

 
Unfortunatly, static isn't an option to me as we have hundreds of users and
run everything under suexec.

I'm glad at least someone else has experienced the issue...  If anyone has a
fix workaround, that would be great ;)



- Matt


-----Original Message-----
From: Chris Lightfoot [mailto:chris-Fh87UKZVeM/RBZ/RhJC5oVcZoxXaR/[email protected]] On Behalf Of
Chris Lightfoot
Sent: Tuesday, March 21, 2006 7:35 AM
To: Matt
Cc: fastcgi-developers-xGejAJT2w6xVgU18Zptdi0EOCMrvLtNR@public.gmane.org
Subject: Re: [FASTCGI] Issued with Apache+mod_fastcgi+PHP

On Sun, Mar 19, 2006 at 07:59:00PM -0500, Matt wrote:
    [...]
> What occurs is that with certain (slow) scripts, PHP will continously
spawn
> every n seconds.  I believe I've correlated n to the -startDelay setting,
so
> if its set to 3, it spawns a PHP process every 3 seconds, if its 10, it
> spawns one every 10 seconds.  In any case, the old processes are not
killed
> and you end up with x amount of processes running, to serve a single page
> (and obviously one one of the procs is actually returning results).  I
fear
> that this behavior will result in a single page will consume the resources
> alotted.
> 
> Any suggestions on how to workaround this situation, or am I missing some
> inherit setting that may help to appease the situation?   I have
> experimented with most of the settings above, but wasn't able to get
> acceptable behavior. 
> 
> I've tested it on a server with 3 sites and a server with 300, and it
> behaves the same in both.

yeah. We had this problem with RT, which uses 50--100MB of
unshared memory for each instance (it's a gigantic perl
program); it processes email by having it passed in an
HTTP POST to the RT application, and then does various
SpamAssassin checks which can take a while (waiting for
DNS results, I suspect, but I got kind of bored of
debugging this at that point). So during a ~30s period
while the first instance of mason-handler.fcgi is
processing a mail, the process manager spawns another
instance every 3s. Obviously if at this point you don't
have half a gigabyte of spare memory knocking around
you're in a certain amount of trouble.

We fixed this by running the application as a static
FastCGI process with a fixed limit of three extant
processes, though this is hardly ideal. I spent a little
while reading the process manager code to try to
understand its strategy (obviously it oughtn't to start
further instances of the application unless there're
further requests to process, but it does anyway); however,
the code's a bit tangled and I try to avoid hacking on
nonfree software for no reward if I can possibly avoid it.

I take it there hasn't been any progress in relicensing
mod_fastcgi?

-- 
Chris Lightfoot
mySociety

___________________________________
fastcgi-developers mailing list
http://fastcgi.com/fastcgi-developers/