I have a strange problem running PHP5.3.3 on a Windows 2003 server with Apache.
Sometimes scripts that have been initiated finish the work that they are doing, but the process does not close.
This can leave a large number of orphan php-cgi.exe processes running, but not, apparently, doing anything (not using any CPU time).
After a while, these build up and cause performance issues on the server.
There doesn't seem to be a fault with the PHP script itself, as normally it runs and closes fine, it's just somethings it doesn't, and there doesn't seem to be any obvious pattern about it either.
Also, we didn't have this problem before moving from PHP4 to PHP5.3.
Any ideas? It feels like some config I've got wrong in Apache or PHP somewhere? I am NOT using the apache dll to run PHP,and neither is this an option for 开发者_StackOverflow社区me.
thanks in advance
There can be three reasons for this, since you say "orphaned" I suspect it may be number 2.
When launching php-cgi, php starts it's on thread control manager. On unix you normally only let that manager spawn one child thread, since apache already does the management of the processes.
This process is then reused for new incoming requests after the initial one is finished, because it saves time (parsing .ini file, loading libraries etc.). After a number of reuses this process is then killed and a new one is spawned if needed. If this is the case, it is actually a good behavior. Page loads would take quite a while longer otherwise.
However, since there are performance issues, I would recommend checking the following:- Tweak the fcgid settings (if you are not using mod_fcgid, I would definitely recommend it. Here's a little tutorial).
- Make sure PHPs thread control manager is turned off. Only one request is sent to it at once anyways (PHP_FCGI_CHILDREN=1)
If those things do not help, you might have a problem with your launch script. When I first started using apache with fcgid I wrote the launch script for php-cgi myself instead of copying. I forgot a tiny little
exec
in fornt of the command that launches the php-cgi.
This caused the cgi to be launched as a child process to the script process.+apache2 |-+shell-launch-script.sh |-+php-cgi
What this meant was, that once apache decided to kill the script because it had served enough pages, the child process of the script was orphaned and became a direct descendant of the init process. Once there the cgi processes were never terminated and filled up the memory.
Theexec
command causes the php-cgi process to take over the shell script process and run in its place. So when apache sends a kill signal to its child process, php is killed and not only the launch-script.
I suspect something like that may also be the case with your launch script.
You can verify if this is the case with the Process Monitor. I do not know the exact workings of windows process management, so you may get a false negative confirmation (meaning, they are still children of the apache process, but apache cannot signal them to terminate).If you are using fastcgi and not fastcgid, you may have a problem they talk about in the documentation:
Under Windows, there are no signals. A shutdown event is used instead. This is setup by mod_fastcgi and honored by the latest version of the C, C++, and Perl application library. If your using a library which doesn't support this, your application will not get shutdown during an Apache restart/shutdown (there's room for improvement here).
From the fastcgi documentation in the Notes section.
Disclaimer: These observations originate from a Unix system, but my guess is, that the CGI part should work the same way on windows.
精彩评论