Further discussion: Nginx 502 Bad Gateway error resolution _php instance

MAX_CHILDREN=40, each children occupies the average 20m-30m memory, the more children, can accept concurrently the number of concurrent, the general children value is the maximum number of concurrent sites + floating value, this value and then x memory footprint, is that you need to use the memory.
Max_requests = n means that when each children accepts N requests, it kills itself and then builds a children.
Pv/max_children = number of requests received per children [default preset browsing a PHP program only once, perhaps asynchronously? What about the interface? ]
For example, the value above is 1000, and you define 10240, then fpm to kill children and rebuild for more than 10 days, so that if there is a memory leak, it will cause the process to occupy too much memory and can not be released, so that the processing power of FPM lower, but also produce some inexplicable errors.
But if you set this value too small, fpm frequently kills children and rebuilds, causing additional overhead.
The best optimization of course is based on the operation of your site, to continue to debug, find a balance point.
There's also a lazy approach to max_children, If your PHP is 5.3, then you can set the FPM style to Apache-like, this time the number of children by FPM automatic control. The corresponding configuration parameters are
Start_servers: Number of start processes
Min_spare_servers: Minimum number of processes
Max_spare_servers: Maximum number of processes
When the server is more idle, FPM will take the initiative to kill some redundant children, to save resources, when the server is busy, the server will automatically build more children.
#########################
Nginx 502 Bad Gateway means that the requested php-cgi has been executed, but the php-cgi process is terminated for some reason (typically a problem reading the resource) is not completed.
Generally speaking Nginx 502 bad Gateway and php-fpm.conf settings are relevant.
Php-fpm.conf has two critical parameters, one is Max_children,
The other is request_terminate_timeout, but the value is not universal, but it needs to be calculated by itself.
There are 502 problems with the installation process, typically because the default php-cgi process is 5, which can result in 502 due to insufficient phpcgi processes and needs to be modified/usr/local/php/etc/php-fpm.conf Max_ The children value is increased appropriately.
The method of calculation is as follows:

If your server performance is good enough and the broadband resources are sufficient, PHP scripts do not die loops or bugs, you can set the request_terminate_timeout directly to 0s. The meaning of 0s is to allow php-cgi to carry on without any time limit. And if you can't do this, which means that your php-cgi may have a bug, or that your broadband isn't enough or that other reasons are causing your php-cgi to die, then it's recommended that you assign a value to Request_terminate_timeout. This value can be set according to the performance of the server. Generally the better performance you can set the higher, 20 minutes-30 minutes can be.

And Max_children This value is how to calculate it? This value is in principle the bigger the better, the php-cgi process will be processed more quickly, the queue of requests will be very little. Setting Max_children also needs to be set according to the performance of the server.
In general, a server normally consumes about 20M of memory per php-cgi.
According to the official answer, to troubleshoot the relevant possibility, and combined with the user's answer, came to the following solution.
1, view the PHP fastcgi number of processes (Max_children value)
Code: Netstat-anpo | grep "php-cgi" | Wc-l
5 (if shown 5)
2. View current Process
Code: Top
Observe the number of fastcgi processes, if the number of processes used is equal to or higher than 5, indicating the need to increase (depending on the actual situation of your machine)
3, adjust the relevant settings of/usr/local/php/etc/php-fpm.conf
<value name= "Max_children" >10</value>
<value name= "Request_terminate_timeout" >60s</value>
Max_children up to 10 processes, 20MB memory per process, up to 200MB.
The Request_terminate_timeout execution time is 60 seconds, which is 1 minutes.
#################################################
The operating environment of the Web site is nginx +php fastcgi mode. These days have been running unstable, always error, reported 502 errors.
I consulted with my former colleagues today and he told me to check the PHP-FPM log, where a lot of useful information was recorded.
So I checked and found that there were a lot of error messages:
Sep 08:32:23.289973 [NOTICE] Fpm_unix_init_main (), line 271:getrlimit (nofile): max:51200, cur:51200
if and Nginx.conf:worker_rlimit_nofile 65500; Inconsistencies must be checked, set restart service
Mar 14:39:15.881047 [NOTICE] Fpm_children_make (), line 352:child 12364 (pool default) started
Mar 14:39:21.715825 [NOTICE] fpm_got_signal (), line 48:received SIGCHLD
Mar 14:39:21.715899 [NOTICE] Fpm_children_bury (), line 215:child 11947 (pool default) exited with code 0 after 175.443 305 seconds from Start


Some error information, just say, directly on the Internet to check information.
After the search, finally summed up the following several optimization strategies:
1, raise the server's file handle open Open
# vi/etc/security/limits.conf Plus
* Soft Nofile 65500
* Hard Nofile 65500
2, the promotion Nginx process file open number
Nginx.conf:worker_rlimit_nofile 65500;
3, modify the php-fpm.conf document, the main need to modify 2 places.
Command Ulimit-n View the number of open files that are restricted, and the options in php-fpm.conf rlimit_files ensure that they are consistent with this value.
<value name= "Max_requests" >10240</value>
<value name= "Rlimit_files" >65500</value>
4,
# vi/etc/sysctl.conf
Bottom add
fs.file-max=65500
After the above changes, restart PHP. /USR/LOCAL/WEBSERVER/PHP/SBIN/PHP-FPM restart
Reboot the server or/etc/sysctl.conf,/etc/security/limits.conf configuration takes effect when viewing whether ulimit-n is in effect
So far, there have been no more error messages. Everything works fine.