Re: Processes dying prematurely

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/