Solution to the problem of a large number of php-cgi.exe processes on the server causing the CPU to occupy 100%

Optimize the fastcgi configuration file fcgiext.ini in Windows 2003+IIS6 to reduce the number of php-cgi.exe processes and the size of memory occupied

I heard that fastcgi is better than isapi, so I installed it on the server. The configuration environment is windows 2003+IIS6+fastcgi(FCGI)+PHP5.2.17. After observing for a long time, I found that PHP working in FastCGI mode will occupy more and more memory. If the number of visits is slightly higher, there will be N more php-cgi processes. Under the same circumstances, it can take up hundreds of MB more than when using isapi mode. My server has only 2G of memory and I can't afford it.

I searched online and found that many people are facing the same problem. A more formal explanation from PHP officials is that there is no memory leak in the php-cgi process. php-cgi will recycle all the memory used by the script at the end of each request, but will not release it to the operating system, but will continue to hold it to cope with the next PHP request. This is probably done to reduce memory fragmentation or to solve the problem of uncontrollable time required to request memory from the system and release it back to the operating system. However, if a PHP request occasionally uses a large memory operation such as ftp or zlib, a large block of system memory will be continuously occupied by php-cgi and cannot be used.
The solution to this problem is to optimize the fastcgi configuration file parameters in the web server configuration.

In the C:\WINDOWS\system32\inetsrv\fcgiext.ini file, you can set the php-cgi process related parameters, such as:

[Types]
php = PHP
[PHP]
ExePath=C:\php-5.3.8-nts-Win32-VC9-x86\php-cgi.exe
maxInstances=100
InstanceMaxRequests=10000
EnvironmentVars=PHP_FCGI_MAX_REQUESTS:10000
RequestTimeout=600
ActivityTimeout=900

In the above configuration:

ExePath specifies the path of the FastCGI parser.
instanceMaxRequests specifies the maximum number of requests that each instance can handle.
maxInstances specifies the maximum number of instances that can be started.
EnvironmentVars creates an environment variable PHP_FCGI_MAX_REQUESTS with a default value of 10000.
requestTimeout specifies the request timeout as 600 seconds.
activityTimeout specifies the activity session timeout to 900 seconds.
The following are recommended values:
maxInstances=
Change this value to a smaller value

suggestion

For 512M memory, change maxInstances=50
For 1G memory, change maxInstances to 80
For 2G memory, change maxInstances to 140

Modify again
InstanceMaxRequests=
Change this value to a smaller value

suggestion

For 512M memory, change InstanceMaxRequests=200
For 1G memory, change InstanceMaxRequests=300
For 2G memory, change InstanceMaxRequests=500

After the change, restart IIS.

instanceMaxRequests PHP_FCGI_MAX_REQUESTS These two parameters determine the maximum number of PHP requests that a php-cgi process can accept after it is created. The default configuration in lighttpd is 10000. That is to say, this php-cgi process will terminate after receiving 10,000 PHP requests, release all memory, and be restarted by the management process. If you lower it, for example to 100, the php-cgi restart cycle will be greatly shortened, and the impact time of problems caused by occasional high memory operations will also be shortened.
maxInstances This parameter specifies the maximum number of instances that can be started, that is, the number of php-cgi.exe processes. If you lower it, for example to 100, then there will be at most only the php-cgi.exe process in the task manager's processes, and the total memory occupied by php-cgi.exe will be greatly reduced.
The server I am using now is Windows 2003 operating system, 4G memory, and a php-cgi.exe program occupies 7-25M memory. I adjusted the maxInstances value to 300, which reduced the total number of php-cgi.exe processes and the memory occupied. The response speed is much faster than before. The minimum adjustment value can be determined based on the number of visits to your site.

Win2008 server, fastCGI perfect setting tutorial

When using FASTCGI to call PHP-CGI.EXE on IIS7 of WIN2008, there are only 4 processes by default. For websites with large traffic, the process queuing caused by insufficient number of processes is very serious. The solution is as follows.

32-bit systems http://www.iis.net/Downloads/files/AdminPack/TP2/AdminPack_x86.msi
64-bit systems http://www.iis.net/Downloads/files/AdminPack/TP2/AdminPack_amd64.msi

Download the following tool and install it as shown below.

Add to

PHP_FCGI_MAX_REQUESTS = 10000

After adding, you can see the effect in the process manager without restarting IIS.

It doesn't seem to have reached the set value, but the performance improvement is obvious when browsing the website.

Memory usage~~ In fact, one disadvantage of Microsoft's system is that the server's memory usage should be used by services as much as possible, instead of leaving enough memory for user applications like the client.

I would like to remind you that the following two parameters are worth setting:

InstanceMaxRequests: The maximum number of requests that the fastcgi process (php-fcgi.exe) can handle. If it exceeds the limit, it will be recycled. The default value is 200

PHP_FCGI_MAX_REQUESTS: The maximum number of requests controlled by PHP itself, the default is 500

Since you want to use fastcgi to run cgi, you definitely don't want php itself to limit the maximum number of requests! !

Therefore, be sure to ensure that InstanceMaxRequests is less than or equal to PHP_FCGI_MAX_REQUESTS, so that PHP itself will never have the opportunity to recycle the process.

You can see what micorsoft said:

Make sure that FastCGI always recycles Php-cgi.exe processes before native PHP recycling starts. The configuration property instanceMaxRequests controls the FastCGI process-recycling behavior. This property specifies how many requests FastCGI will process before recycling. PHP also has a similar process-recycling functionality that is controlled by the environment variable PHP_FCGI_MAX_REQUESTS. By setting instanceMaxRequests to a value that is smaller than or equal to PHP_FCGI_MAX_REQUESTS, you can make sure that the native PHP process-recycling logic will never start.

Solution to the problem of too many php-cgi.exe processes on the server causing 100% CPU usage

When using IIS server, there are often too many php-cgi.exe processes, which causes the CPU to occupy 100%, and eventually causes the website to run too slowly or even freeze. Restarting IIS will be fine for a while, but this situation will recur after a while. Why does this happen and how should it be solved? At the beginning, I always manually ended the php-cgi program. Although it can temporarily solve the problem, it is not a long-term solution. I searched on Baidu and found that this problem is generally a program problem, such as the program using fastcgi to run PHP, and the StartProcesses set by the program is too large, such as 6 or even larger. The following is my solution to the problem of excessive php-cgi.ext causing server cup%; I hope it will be helpful to you; most of the time it happens in the fourth item;

Solution reference:

1. Check the system disk space. Check whether there are too many temporary files in the system. The temporary files of the MySQL database are stored in c:/windows/temp by default, resulting in the accumulation of tens of thousands or even millions of small files, overwhelming the system disk.

del *.* delete all files

If the above command is not powerful enough, you can use the following code

del /f /q /s tmp\*.*

2. PHP is a widely used dynamic scripting language, but there is no built-in support for the PHP language in IIS, so if you need to use PHP, you must install it yourself. PHP can be installed in CGI mode or ISAPI mode. Since ISAPI mode has higher performance, I recommend that you use ISAPI mode.

3. If the program can be modified, it is recommended to reduce the StartProcesses value in the program configuration file to 2 to see if it improves the situation.

4. Check whether there is any problem with the server or any attack phenomenon.