ID: 43105
Comment by: marcus dot mueller at grintsch dot com
Reported By: ian at onlineloop dot com
Status: Assigned
Bug Type: Apache2 related
Operating System: Solaris 10
PHP Version: 5.2.5RC2-dev
Assigned To: ab5602
New Comment:
As I stated above we have this issue on two Linux boxes with
self-compiled PHP binaries. These were compiled using gcc!
Previous Comments:
------------------------------------------------------------------------
[2007-11-28 16:36:24] ian at onlineloop dot com
Coming back to the bug report here now.
In the meantime some private emails were exchanged, including a pfiles
output from Solaris showing that PHP had over 210,000 open files after
24 hours running on our servers. Within 48 hours (we let it go this far
onyl once), apache/php eats around 12Gb of RAM and has between 170 and
220 child processes with over 230,000 open files. Under 5.1.6 the usage
is more around 1.5-2Gb ram, and 30-70 child processes, with rarely more
than 100 open files (only when we are really under load do we get to
more than about 800 open files at any one time).
A small patch was sent to me to try, however this has changed nothing.
I was also asked to compile with gcc if possible, however this is not
feasible as too many other things would have to be recompiled. Besides,
we specifically went away from gcc because everything we had that was
compiled with gcc was seg faulting all the time, however with the Sun
Studio compiler suite, everything is stable.
I seriously doubt this is an apache bug, why were things working with
previous versions of PHP, and not this one?
------------------------------------------------------------------------
[2007-11-28 15:02:11] grknight at iwon dot com
I am also experiencing this issue.
We are running Apache 2.2.3 on Redhat EL 3 and recently tried to update
to 5.2.5 from 5.2.3 to fix the security issues. The moment 5.2.5 was
activated, connections failed to close in apache and resulted in hung
processes. I also tried 5.2.4 with the same results.
No configurations were changed nor PHP scripts.
Something changed in the PHP processes that prevents the apxs2handler
from exiting between 5.2.3 and 5.2.4.
Configs available on request.
------------------------------------------------------------------------
[2007-11-26 14:08:48] marcus dot mueller at grintsch dot com
I doubt this is an Apache issue since we're experiencing the same
symptons as hwallenstone at gmx dot here on two debian linux boxes, one
using the 64bit version of Apache's httpd 2.2.4, the other using the
32bit version of httpd 2.0.59.
httpd processes seem to hang i.e. they don't close the connection
(telling from /server-status) resulting in the issues mentioned above.
I first noticed this behaviour when switching from PHP 5.2.3 to PHP
5.2.4, both self-compiled using the same configure options. PHP 5.2.3,
unlike 5.2.4 and 5.2.5, does not expose this behaviour.
I hope this info might narrow down your search path a little bit.
------------------------------------------------------------------------
[2007-11-25 14:21:58] hwallenstone at gmx dot de
I think we have the same problem here. I have updated one server of a
cluster of busy servers from a patched 5.2.1 to 5.2.5 . The number of
apache processes is growing and as a consequence of this, the number of
open files increases. We have about 50 processes running on average
machines; on the 5.2.5-one the number constantly grows until it reaches
my MaxClients Limit. Trying to stop apache, I get hundreds of entries
like
[Sun Nov 25 14:14:55 2007] [error] could not make child process 28546
exit, attempting to continue anyway
This problem **definitely** has come with the upgrade from 5.2.1 to
5.2.5. Nothing else was changed. So it doesn't look like this is a old
apache bug.
------------------------------------------------------------------------
[2007-11-20 09:40:33] [EMAIL PROTECTED]
IIRC, this is actually an Apache bug. PHP is not the only module which
suffers as 3rd party of it..
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/43105
--
Edit this bug report at http://bugs.php.net/?id=43105&edit=1
