502 Bad Gateway (PHP angle to analyze)

1th: Resource problems caused by request_terminate_timeout if the value of Request_terminate_timeout is set to 0 or too long, it may cause file_get_contents resource problems. If the remote resource requested by file_get_contents is too slow, file_get_contents will remain stuck there and will not time out.
We know php.ini inside.Max_execution_timeYou can set the maximum execution time for PHP scripts, but in php-cgi (PHP-FPM), this parameter is not effective. The real ability to control the maximum execution time for PHP scripts is in the php-fpm.conf configuration file.Request_terminate_timeoutParameters. The default value for Request_terminate_timeout is 0 seconds, meaning that the PHP script will continue to execute. This way, when all the php-cgi processes are stuck in the file_get_contents () function,
This nginx+php WebServer can no longer handle the new PHP request, Nginx will return to the user "502 Bad Gateway". To modify this parameter, it is necessary to set the maximum execution time for a PHP script, but the symptom is not a cure. For example, to 30s, if a file_get_contents () gets a slower page content,
This means that 150 php-cgi processes can handle only 5 requests per second, and WebServer is also hard to avoid "502 bad Gateway". The workaround is to set the request_terminate_timeout to 10s or a reasonable value, or to add a timeout parameter to file_get_contents. $ctx = stream_context_create (Array (' http ' = = = Array (' timeout ' = 10//Set a time-out, in seconds)); File_get_co  Ntents ($str, 0, $ctx); 2nd: Improper configuration of the max_requests parameter may cause an intermittent 502 error:pm.max_requests = +;Sets the number of requests for the service before each child process is reborn. is useful for third-party modules that may have a memory leak. If set to ' 0′, the request is always accepted. Equivalent to the PHP_FCGI_MAX_REQUESTS environment variable. Default value: 0. This configuration means that the process is automatically restarted when the number of requests processed by a php-cgi process accumulates to 1000. But why restart the process? Generally in the project, we will more or less use some PHP third-party libraries, these third-party libraries often have a memory leak problem, if you do not periodically restart the php-cgi process, it is bound to cause memory usage is increasing. So php-fpm, as the manager of PHP-CGI, provides such a monitoring function,
Restarts the php-cgi process with a specified number of requests to ensure that the amount of memory is not increased.
It is because of this mechanism, in high-concurrency sites, often lead to 502 of errors, I guess the reason is that php-fpm to the request from NGINX queue is not handled well. However, I am still using PHP 5.3.2, I do not know if there is a problem in PHP 5.3.3. Our solution now is to set this value as large as possible, to minimize the number of php-cgi re-SPAWN (spawning), and to improve overall performance. In our own actual production environment we found that the memory leak was not obvious, so we set the value to very large (204800). We must set this value according to their actual situation, can not blindly increase. In other words, the purpose of this mechanism is only to ensure that the php-cgi does not take up too much memory, so why not handle it by detecting memory? I agree with Gao Chunhui that it would be a better solution to restart the php-cgi process by setting the peak intrinsic consumption of the process.

 In conclusion, in view of the FPM restart, I think we can use the overview of the process pool in fpm, we can set up multiple process pools;

[WWW]
user = www
Group = www
Listen = 127.0.0.1:9001
PM = dynamic
Pm.max_children = 500
Pm.start_servers = 200
Pm.min_spare_servers = 100
Pm.max_spare_servers =

[WWW]
user = www
Group = www
Listen = 127.0.0.1:9000
PM = dynamic
Pm.max_children = 500
Pm.start_servers = 200
Pm.min_spare_servers = 100
Pm.max_spare_servers = 300





Nginx Configuration

Machine a nginx.conf configuration

Increase #在http Area:

Upstream backend{
Server 127.0.0.1:9000 weight=1;
Server 127.0.0.1:9001 weight=2;
KeepAlive 3072;
}

The following configuration is in the #在server

Location ~. *\.php
{
Fastcgi_pass backend;
Fastcgi_index index.php;
Include fastcgi.conf;
}

502 Bad Gateway (PHP angle to analyze)