In-depth discussion: solutions to Nginx 502 Bad Gateway errors

Max_children = 40, each children occupies 20 m-30m of memory on average. The more children, the more concurrency can be accepted at the same time. Generally, the value of children is the highest concurrency of the website + floating value, this value is × memory usage, which is the memory you need.
Max_requests = N indicates that after each children accepts N requests, they will kill themselves and create a new children.
PV/max_children = the number of requests received by each children [by default, a browser browses a PHP program that calls only once, maybe asynchronously? What about interfaces?]
For example, if the above value is 1000 and you define 10240, fpm takes more than 10 days to kill the children and recreate it. If there is a memory leak, this will cause the process to occupy too much memory and cannot be released, thus reducing the fpm processing capability and causing some inexplicable errors.
However, if you set this value too small, fpm will frequently kill children and recreate it, which will also lead to additional overhead.
The best optimization is, of course, to continuously debug and find a balance point based on the running status of your website.
There is also a lazy approach for max_children, If your php is 5.3You can set the fpm style to apache-like. In this case, the number of children is automatically controlled by fpm. The corresponding configuration parameters are:
Start_servers: Number of starting processes
Min_spare_servers: Minimum number of processes
Max_spare_servers: Maximum number of processes
When the server is idle, fpm will take the initiative to Kill unnecessary children to save resources. When the server is busy, the server will automatically create 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 (generally because the problem of reading resources) is not completed,
In general, Nginx 502 Bad Gateway is related to the php-fpm.conf settings.
The php-fpm.conf has two crucial parameters: max_children,
The other is request_terminate_timeout. However, this value is not common and needs to be calculated by itself.
502 problems occur during installation and use. Generally, the default php-cgi process is five, which may be caused by insufficient phpcgi processes, you need to modify/usr/local/php/etc/php-fpm.conf to add the max_children value as appropriate.
The calculation method is as follows:

If your server has good performance and sufficient bandwidth resources, you can directly set request_terminate_timeout to 0 s if the PHP script does not have an endless loop or BUG. 0 s means to keep the PHP-CGI running without a time limit. If you can't do this, it means that your PHP-CGI may have a BUG, or if your bandwidth is insufficient or your PHP-CGI is suspended for other reasons, it is recommended that you assign a value to request_terminate_timeout, which can be set based on the server performance. In general, the better the performance, the higher you can set, 20 minutes-30 minutes can be set.

How does max_children calculate the value? In principle, the larger the value is, the better. If the php-cgi process is too large, it will process very quickly and there will be very few requests in the queue. Setting max_children also depends on the server performance,
Generally, a server normally consumes about 20 mb of memory per php-cgi.
According to the official answer, I checked the relevant possibilities and combined the answers from netizens to find the following solutions.
1. view the number of php fastcgi processes (max_children value)
Code: netstat-anpo | grep "php-cgi" | wc-l
5 (for example, 5)
2. view the current process
Code: top
Observe the number of fastcgi processes. If the number of processes used is equal to or higher than 5, increase the number (depending on the actual situation of your machine)
3, adjust/usr/local/php/etc/php-fpm.conf settings
<Value name = "max_children"> 10 </value>
<Value name = "request_terminate_timeout"> 60 s </value>
Max_children can have a maximum of 10 processes. Each process has 20 MB of memory and a maximum of 200 MB.
Request_terminate_timeout: the execution time is 60 seconds, that is, 1 minute.
######################################## #########
The website runtime environment is in Nginx + php fastcgi mode. The operation has been unstable over the past few days, and errors always occur. The error 502 is reported.
Today, I asked my colleagues to check the php-fpm logs, which recorded a lot of useful information.
So I checked and found a lot of error messages:
Sep 30 08:32:23. 289973 [NOTICE] fpm_unix_init_main (), line 271: getrlimit (nofile): max: 51200, cur: 51200
If it is inconsistent with nginx. conf: worker_rlimit_nofile 65500, you must check and restart the service.
Mar 01 14:39:15. 881047 [NOTICE] fpm_children_make (), line 352: child 12364 (pool default) started
Mar 01 14:39:21. 715825 [NOTICE] fpm_got_signal (), line 48: received SIGCHLD
Mar 01 14:39:21. 715899 [NOTICE] fpm_children_bury (), line 215: child 11947 (pool default) exited with code 0 after 175.443305 seconds from start

If some errors are reported, you can check the information online.
After searching, the following optimization strategies are summarized:
1. open the file handle of the server
# Add vi/etc/security/limits. conf
* Soft nofile 65500
* Hard nofile 65500
2. Increase the number of opened processes in nginx
Nginx. conf: worker_rlimit_nofiles 65500;
3, modify the php-fpm.conf file, mainly need to modify 2.
Command ulimit-n to view the limit on the number of opened files, the option rlimit_files in the php-fpm.conf is sure to be consistent with this value.
<Value name = "max_requests"> 10240 </value>
<Value name = "rlimit_files"> 65500 </value>
4,
# Vi/etc/sysctl. conf
Add at the bottom
Fs. file-max = 65500
After the above modification, restart PHP. /Usr/local/webserver/php/sbin/php-fpm restart
Check whether ulimit-n is effective. Otherwise, restart the server or configure/etc/sysctl. conf and/etc/security/limits. conf to take effect.
So far, no above error messages have been reported. Everything runs normally.