Re: Processes dying prematurely

All it is, is the wrapper.  I wasn't using a wrapper, so it didn't spawn
any children.  I guess the environment variable that says spawn children,
tells it that it needs to.

Interesting... so, does this mean that if -maxClassProcess is set to 5, and
 you set max children to 2, that you can have 5 parents processes with 2
children a piece?  So you end up with 10 php fastcgi's running?

Thanks,
Ben

On 8:54:42 am 08/25/06 "Ben Chabot" <[email protected]> wrote:
> Well, it may be my mistake in the setup.  What is your "php-pm"?  I am
> calling this binary directly from fcgi-pm :
>
> [root@berkana cgi]# pwd
> /usr/amnet/php-4.4.2/sapi/cgi
> [root@berkana cgi]# ./php -v
> PHP 4.4.2 (cgi-fcgi) (built: Aug 24 2006 09:54:24)
> Copyright (c) 1997-2006 The PHP Group
> Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies
>
>
> I may have simply set this up incorrectly.  Should I be calling
> something else?  Is there a php-pm application somewhere that calls
> these workers? Or is php with --enable-fastcgi supposed to spawn
> workers on it's own?
>
> I am calling it from a modified suexec, but I don't think that would
> prevent it from calling children if it was supposed to.  I think I
> must just have a misconfiguration?
>
> Thanks,
> Ben
>
> On 8:33:26 am 08/25/06 David Birnbaum <[email protected]> wrote:
> >  Ben,
> >
> >  I think it would be worth finding out who on the PHP team wrote
> >  this code, and ask them why:
> >
> >  -  it's exiting so much, and;
> >  -  why your PHP and my PHP seem to function differently
> >
> >  In my case, I have the fcgi-pm forking the php-pm, which forks the
> >  php-workers. In your case, the fcgi-pm forks the php-workers
> >  directly.  This is BAD, because under high load the workers are
> >  killing themselves too quickly.  You could try tuning the dynamic
> >  proc manager to be more tolerant of things dying quickly (ie, move
> >  it down from 30 seconds to 5 seconds) which will at least stop the
> >  symptom. I have a php-pm under 4.3.X, 5.0.X, and 5.1.X - it works
> >  the same across the board.  We seem to have them built the same
> >  way, yet the end result is manifestly different.
> >
> >
> >  David.
> >
> >  -----
> >
> >  On Thu, 24 Aug 2006, Ben Chabot wrote:
> >
> > >   Well, after more investigation, I saw that on the good vhost,
> > >   the daemon was resetting every 500 requests and restarting.  On
> > >   the other one, it was resetting after 500, and not restarting.
> > >   I wonder if it's because on the one that was not working, it
> > >   seems to require multiple php scripts to run for each page
> > >   load.  Like it was dying in the middle of a page load?
> > >
> > >   At any rate, I looked at the php cgi source :
> > >
> > >   [root@berkana cgi]# pwd
> > >   /usr/amnet/php-4.4.2/sapi/cgi
> > >
> > >   And changed what was 500 to 2000 :
> > >
> > >   [root@berkana cgi]# grep 2000 cgi_main.c
> > >          int max_requests = 2000;
> > >
> > >   I know you can do this in the environment too, but this seems to
> > >   have fixed it on the vhost that was not working.  It's as if,
> > >   fcgi-pm restarts php before it hits the 2000 limit.  Is
> > >   fcgi-pm's restart based on time? In the log file it's the
> > >   normal sequence now... (1) termination signaled (2) terminated
> > > (3) restarted.
> > >   For all the vhosts, none are dying spontaneously... yet anyway.
> > >   Do you have any idea why this seems to have improved the
> > >   situation?  It seems to me that if fastcgi is going to be
> > >   restarting the php-fcgi daemon, then why does it need to kill
> > >  itself after X many requests?
> > >   (And David Birnbaum, you were right, even though I hadn't set
> > >   the environment variable, it was still dying after 500
> > >  requests, very odd.)
> > >   Thanks,
> > >   Ben
> > >
> > >   Chris Lightfoot wrote:
> > >>   build a copy of PHP with debugging symbols and attach gdb
> > >>   to the instance which dies frequently; put a break on the
> > >>   exit function and _exit syscall, and wait for the process
> > >>   to exit. When it does, examine the state of the process to
> > >>   identify what's causing it to do so.
> > >>
> > >>
> > >   ___________________________________
> > >   fastcgi-developers mailing list
> > >   http://fastcgi.com/fastcgi-developers/
>
> ___________________________________
> fastcgi-developers mailing list
> http://fastcgi.com/fastcgi-developers/

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