RE: Apache2 PHP mod_fcgi HTTP 500 errors

dynamicMaxClass is a warning for you, it shouldn't generate an error.  It does 
indicate that, in the opinion of FastCGI, PHP is not parsing pages fast enough.

David.

-----

On Mon, 31 Oct 2005, RupS wrote:

> Thanks for your reply. I was considering to minimize the PHP_CHILDREN
> variable anyway, I'll do that.
>
> Just to be sure, the dynamicMxClassProcs generates an error 500 right? It's
> not that the page will load correctly after respawning a process? In that
> case I'm afraid it's not going to be accepted by customers.
>
> -----Original Message-----
> From: David Birnbaum [mailto:[email protected]]
> Sent: maandag 31 oktober 2005 20:47
> To: [email protected]
> Cc: fastcgi-developers-xGejAJT2w6xVgU18Zptdi0EOCMrvLtNR@public.gmane.org
> Subject: Re: [FASTCGI] Apache2 PHP mod_fcgi HTTP 500 errors
>
> That's certainly been my experience; that's how the PHP developers chose to
> implement the FastCGI library.  However, if you can live with the
> dynamicMxClassProcs errors, it should work OK.  You might also want to set
> PHP_CHILDREN (or whatever the ENV is these days) to something closer to 2 or
> 4
> so you don't get 8 springing up each time a web site takes a hit.
>
> David.
>
> -----
>
> On Fri, 28 Oct 2005, [email protected] wrote:
>
>> Hi all,
>>
>> I still got a question on this.
>> So what you are saying is, that PHP is just not going to run smoothly with
>> a FastCgiConfig (dynamic) setup?
>>
>> Defining a static config is not an option I'm affraid becasue it does not
>> allow me to specify VirtualHost specific configurations, so using suexec
>> for security is not possible then.
>> Also, with a static config all PHP processes will keep running, which is
>> fine ifyour talking about 1 site, not when you try to server thousands of
>> websites...
>>
>> We have the same problem with our FastCgi setup. I get a lot of:
>> Oct 28 10:05:01 www3 fcgi-[6285]: [warn] FastCGI: scheduled the start of
>> the last (dynamic) server "/path/to/php.sh" process: reached
>> dynamicMaxClassProcs (1)
>> errors.
>>
>> Is there really no way to get this working properly? Is it an option to
>> let FastCgi manage the processes and define zero children for PHP?
>>
>> Thanks for your time,
>> Regards,
>>
>> Ruben van der Zwan
>>
>>
>>
>>> Ah - you are using dynamic.  That don't mix with PHP, sadly.
>>>
>>> I recommend that you use static, and not dynamic, since PHP has its own
>>> process
>>> manager.  Or, if you use dynamic, you tune it carefully to ensure it
>>> doesn't
>>> ever stop running.  FastCGI can't tell what's going on properly, because
>>> the
>>> number of servers it *thinks* are running does not equal the number that
>>> actually are.  I think if you set the maxprocesses to 1, dynamic might
>>> work
>>> right, but I've never tried it.
>>>
>>> We've run PHP in static mode with no problems.
>>>
>>> David.
>>>
>>> -----
>>>
>>> On Mon, 24 Oct 2005, Stefan Wendt wrote:
>>>
>>>> Hi David,
>>>>
>>>> The process you mean seams to work this way:
>>>> - each individual php child process has a counter
>>>> - if the counter is >= MAX REQUEST (something like 500) then the child
>>>> terminates
>>>> - the php parent process detects that by the signal send from the child
>>>> and
>>>> forks a new child
>>>>
>>>> This is all happening inside the compiled PHP_CGI though. You can
>>>> obsever
>>>> this
>>>> nicely with a trace on the php parent process.
>>>>
>>>> I think the problem I have is not related to the communication inside
>>>> the
>>>> php_fcgi.
>>>>
>>>> The documentation on mod_fcgi and fcgi indicate that there is some logic
>>> that
>>>> automatically
>>>> starts-up and shuts-down php processes. Each php process is in turn
>>>> responsible to fork the
>>>> MAX_CHILDREN  worker processes.
>>>>
>>>> So I think the problem happens between the mod_fgci and the php parent
>>>> process.
>>>>
>>>> I am not sure what side to blame though. One could argue that PHP should
>>> wait
>>>> until all children are finished before exiting from the SIGTERM signal.
>>>> On the other hand one could think that mod_fcgi should not try to
>>> terminate a
>>>> php parent process before all jobs are finished.
>>>>
>>>> Also, I don't want to rule out that there is something wrong with my
>>>> setup.
>>>> I have to say that I am surprised to see the mod_fcgi to create more
>>>> than
>>>> one php parent process. Frequently, I have more than 3 php parent
>>>> processes
>>>> running each with 10 child processes all for the same virtual host. I
>>>> expected
>>>> to see only one php parent process with 10 child process for each
>>>> virtual
>>>> host.
>>>>
>>>> I am confused ;)
>>>>
>>>> Thanks for your help ...
>>>>   Stefan Wendt
>>>>
>>>> David Birnbaum wrote:
>>>>
>>>>> Stefan,
>>>>>
>>>>> php seems to restart its children automatically from time to time, I
>>>>> suspect as a way to get reclaim memory from leaks.  Is it possible the
>>>>> problem is due to the php process not completing its work when it
>>>>> receives
>>>>> the SIGTERM?
>>>>>
>>>>> David.
>>>>>
>>>>>>
>>>>>> I think the information below shows quite clearly that the fcgi-pm(?)
>>>>>> terminates the
>>>>>> php process while 2 of it's child processes still work on a request.
>>>>>>
>>>>>> Thanks for having a look into this ...
>>>>>>   Stefan Wendt
>>>>>>
>>>>
>>>> ___________________________________
>>>> 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/