ID: 43105
Updated by: [EMAIL PROTECTED]
Reported By: ian at onlineloop dot com
Status: Open
Bug Type: Apache2 related
-Operating System: Solaris, Linux
+Operating System: Solaris, Linux, Mac OS X
PHP Version: 5.2.5RC2-dev
New Comment:
Apache 1.3.33 and PHP 5.2.5 running on Darwin Kernel Version 8.11.1
(Mac OS X 10.4.11) compiled with configure command (gcc):
'./configure' '--prefix=/usr/local' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--with-apxs' '--with-kerberos'
'--enable-cli' '--enable-exif' '--enable-ftp' '--enable-mbstring'
'--enable-mbregex' '--enable-sockets' '--with-curl'
'--with-config-file-path=/private/etc' '--sysconfdir=/private/etc'
'--with-mysql=/usr/local/mysql' '--with-mysql-sock=/tmp/mysql.sock'
'--without-pear' '--with-gd' '--enable-gd-native-ttf' '--with-png-dir'
'--with-zlib' '--with-bz2' '--with-libxml-dir'
'--with-mysqli=/usr/local/mysql/bin/mysql_config' '--enable-sqlite-utf8'
'--enable-zip' '--disable-cgi'
doesn't seems to be closing open files (requires, includes etc.) which
ends up with the error "Too many open files" very often.
# apachectl restart
# lsof -u www | wc -l
> 56
# lsof -u www | grep "\.php" | wc -l
no output
After running one PHP script:
# lsof -u www | grep "\.php" | wc -l
> 22
Another page hit:
# lsof -u www | grep "\.php" | wc -l
> 104
And so on... The number of open files just keeps increasing.
For some reason PHP 4.4.7 don't have this behavior, that is, apache
keeps the number of open files somewhat constant when PHP is not
running.
For phpMyAdmin the first entries of lsof looks like:
# lsof -u www | grep "\.php" | head
httpd 678 www 6r REG 14,2 26700 915904
/Users/data/htdocs/mysql/libraries/common.inc.php
httpd 678 www 7r REG 14,2 18504 915886
/Users/data/htdocs/mysql/libraries/core.lib.php
httpd 678 www 8r REG 14,2 2063 915950
/Users/data/htdocs/mysql/libraries/sanitizing.lib.php
httpd 678 www 9r REG 14,2 9447 915968
/Users/data/htdocs/mysql/libraries/Theme.class.php
httpd 678 www 10r REG 14,2 10571 915906
/Users/data/htdocs/mysql/libraries/Theme_Manager.class.php
httpd 678 www 11r REG 14,2 9447 915968
/Users/data/htdocs/mysql/libraries/Theme.class.php
httpd 678 www 12r REG 14,2 33846 915974
/Users/data/htdocs/mysql/libraries/Config.class.php
httpd 678 www 13r REG 14,2 44257 915868
/Users/data/htdocs/mysql/libraries/Table.class.php
httpd 678 www 14r REG 14,2 79607 915957
/Users/data/htdocs/mysql/libraries/common.lib.php
httpd 678 www 18r REG 14,2 1919 915824
/Users/data/htdocs/mysql/libraries/js_escape.lib.php
Previous Comments:
------------------------------------------------------------------------
[2007-11-29 16:03:43] marcus dot mueller at grintsch dot com
As I stated above we have this issue on two Linux boxes with
self-compiled PHP binaries. These were compiled using gcc!
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
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
