Solution of Aliyun ECS host Nginx 502 Bad Gateway problem

See the reason may be not enough php-cgi process, PHP execution time (MySQL slow), or php-cgi process die, there will be 502 errors.

1. In the installed environment, run for a period of 502 problems, generally because the default php-cgi process is 5, probably because the phpcgi process is not enough to cause 502, need to modify/usr/local/php/etc/php-fpm.conf Max_ The children value is increased appropriately.

2. PHP execution Timeout, modify/usr/local/php/etc/php.ini change Max_execution_time to 300

3. Low disk space, you can use the # df-h command to view disk usage

4. The php-cgi process died.

The usual troubleshooting methods are as follows:

1, view the PHP fastcgi number of processes (Max_children value)

# Netstat-anop | grep php-cgi | Wc-l

# Netstat-anpo | grep php-fpm | Wc-l

If the display is 5

2. View current Process
# PS aux | The grep PHP-FPM observes the number of fastcgi/php-fpm processes, and if the number of processes used is equal to or higher than 5, the increase is required.

3, adjust the relevant settings of/usr/local/php/etc/php-fpm.conf

Pm.max_children = 5
Request_terminate_timeout = 60

Max_children up to 5 processes, 20MB memory per process, up to 100MB. Which is 1 minutes. Max_children increase, then php-cgi process will be processed more quickly, the queue of requests will be very little. However, setting the 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. The actual decision is based on the memory purchased by your own server.
The Request_terminate_timeout execution time is 60 seconds and the Request_terminate_timeout 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.

4. The execution time of some PHP programs exceeds the waiting time of Nginx, and the timeout time of fastcgi in nginx.conf configuration file can be increased appropriately, for example:

http
{
......
Fastcgi_connect_timeout 300;
Fastcgi_send_timeout 300;
Fastcgi_read_timeout 300;
......
}

The corresponding request time for fastcgi is increased. But I encountered this problem in practice, set to 500, or will appear, but more than I set 120 time less. Later found that the main is in some post or database operations when this happens, static pages will not appear.
Repeatedly check the problem, debugging, also increased the number of CGI processes.
128
256 plus going may become very slow. The memory footprint is large.
There is another item in the PHP-FPM.CONF setting that might not have been noticed at the time and accidentally changed the value.
Request_terminate_timeout
This value is Max_execution_time, which is the execution script time of the fast-cgi.
0s
0s to be closed, is to carry out indefinitely. (I changed a number when I wasn't looking carefully at the time.)
Find out, the problem is solved, the execution for a long time will not be wrong
In the optimization fastcgi, can also change this value 5s. Look at the effect
4, the head is too big
Nginx, like Apache, has a front buffer limit that allows you to adjust the buffering parameters
Fastcgi_buffer_size 32k;
Fastcgi_buffers 8 32k;
If you are using a Nginx load balancing proxying, adjust
Proxy_buffer_size 16k;
Proxy_buffers 4 16k;
5. HTTPS Forwarding Configuration error
The correct configuration method
server_name www.mydomain.com;
Location/myproj/repos {
Set $fixed _destination $http _destination;
if ($http _destination ~* ^https (. *) $)
{
Set $fixed _destination http$1;
}
Proxy_set_header Host $host;
Proxy_set_header X-real-ip $remote _addr;
Proxy_set_header destination $fixed _destination;
Proxy_pass http://subversion_hosts;
}
6, the Nginx error log opened, found that "Pstream sent too big header while reading response header from upstream" such a false hint, look at the information, the effect is nginx slow Flushing area has a bug caused by our site's page consumption footprint may be too large. Reference to the foreigner to write changes to increase the size of the buffer capacity settings, 502 problem thoroughly resolved, and then the system administrator to adjust the parameters to only retain 2 settings parameters: Client head buffer,fastcgi buffer size.
Http://blog.rackcorp.com/?p=14
7, a server running nginx PHP (FPM) XCache, visit the daily average of 300W PV
Recently, there is often such a situation: PHP page Open very slowly, the CPU usage rate suddenly dropped to very low, the system load suddenly rise to very high, check the traffic card, you will find that suddenly dropped to very low. It only lasts a few seconds and it's back.
Check the PHP-FPM log file and find some clues.
Sep 08:32:23.289973 [NOTICE] Fpm_unix_init_main (), line 271:getrlimit (nofile): max:51200, cur:51200
Sep 08:32:23.290212 [NOTICE] Fpm_sockets_init_main (), Line 371:using inherited socket fd=10,
Sep 08:32:23.290342 [NOTICE] Fpm_event_init_main (), line 109:libevent:using Epoll
Sep 08:32:23.296426 [NOTICE] Fpm_init (), line 47:FPM is running, PID 30587
In front of these lines, is more than 1000 rows of closed children and open children log?
Originally, PHP-FPM has a parameter max_requests, which indicates that each children will be shut down when the maximum number of requests is processed, and the default setting is 500. Because PHP is the request polling to each children, in large traffic, each childre to the max_requests time spent almost, so that all the children basically at the same moment was closed.
During this time, Nginx cannot transfer the PHP file to PHP-FPM processing, so the CPU will be reduced to very low (not to handle PHP, not to execute SQL), and the load will rise to very high (close and open children, nginx wait php-fpm), the network card traffic is also reduced to very low ( Nginx cannot generate data transfer to client)
Solving the problem is simple, increase the number of children, and set max_requests to 0 or a larger value, restart PHP-FPM
The implication of Nginx 504 Gateway time-out is that the requested gateway is not requested, simply that there is no request to the php-cgi that can be executed.
To solve these two problems is a need for comprehensive thinking, in general Nginx 502 bad Gateway and php-fpm.conf settings, and Nginx 504 Gateway time-out is related to the settings of nginx.conf.
The correct setting needs to take into account multiple factors such as the performance of the server itself and the number of visitors.
Fastcgi_connect_timeout 300s;
Fastcgi_send_timeout 300s;
Fastcgi_read_timeout 300s;
Fastcgi_buffer_size 128k;
Fastcgi_buffers 8 128k; #8 128
Fastcgi_busy_buffers_size 256k;
Fastcgi_temp_file_write_size 256k;
Fastcgi_intercept_errors on;
The main setting here is the first three, which is
Fastcgi_connect_timeout 300s;
Fastcgi_send_timeout 300s;
Fastcgi_read_timeout 300s;
This set the php-cgi connection, send and read time, 300 seconds enough to use, so my server rarely appear 504 Gateway time-out this error. The key is the php-fpm.conf setting, which leads directly to 502 bad Gateway and 504 Gateway time-out.
Now let's take a closer look at some of the key parameters of php-fpm.conf:
Php-fpm.conf has two critical parameters, one is "Max_children" and the other is "Request_terminate_timeout"
The value of my two settings is "40″, one is" 900″, but this value is not universal, but it needs to be calculated by itself.
The method of calculation is as follows:
If your server performance is good enough and your broadband resources are sufficient, PHP scripts do not have loops or bugs, you can set the "request_terminate_timeout" to 0s directly. 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 be a bug, or that your broadband is not enough or that other reasons cause your php-cgi to be suspended, then it's recommended that you assign a value to "Request_terminate_timeout", This value can be set according to the performance of your server. Generally the better performance you can set the higher, 20 minutes-30 minutes can be. Because my server PHP script needs to run for a long time, and some may be more than 10 minutes so I set 900 seconds, so that will not cause php-cgi to die and appear 502 Bad Gateway this error.
And how is the value of "Max_children" calculated? This value in principle is the bigger the better, the php-cgi process will be processed more quickly, the queue of requests will be very little. Set "Max_children" also need to set according to the performance of the server, generally a server under normal circumstances of each php-cgi memory consumed in about 20M, so my "Max_children" I set to 40, 20m*40= 800M means that at peak time all php-cgi are consumed within 800M, less than my valid memory 1Gb. And if my "max_children" set smaller, such as 5-10, then php-cgi will be "very tired", processing speed is also very slow, waiting for a long time. If a long time did not get the processing of the request will appear 504 Gateway time-out this error, and are dealing with the very tired of the few php-cgi if encountered problems will appear 502 bad Gateway this error