Recently, the phenomenon of server downtime more frequent, temporary work, G to hang up, 502 Bad Gateway Nginx, I can not help but remind me before the 504 gateway time-out, the two should be a bit of contact, we must find out. 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.
Nginx 504 Gateway In the previous article has been recorded, here for the time being ignored, directly said 502 Bad Gateway solution, the most critical is the php-fpm.conf settings. Php-fpm.conf has two critical parameters, one is "Max_children" and the other is "request_terminate_timeout", and these two values need to be computed.
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 have a bug, or that your broadband isn't enough, or that other reasons cause 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 your server. Generally, the better the performance, the higher you can set.
How is the value of "Max_children" calculated? 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. Set "Max_children" also need to set according to the performance of the server, if each php-cgi the memory consumed in about 20M, "Max_children" set to 80,20m*80= 1600M in other words, in the peak time all php-cgi consumption within 1600M, less than the effective memory can be.
And if "Max_children" set small, 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 is dealing with the "very tired" of the few php-cgi if encountered problems will appear 502 bad Gateway this error.
The following is a more detailed description of the information:
Some websites running on Nginx sometimes appear as "502 Bad Gateway" errors, some times even frequently. The following is a small compilation of some of the Nginx 502 error troubleshooting Methods for reference:
The reason for the Nginx 502 error is more due to a problem with the backend server in Agent mode. These errors are generally not nginx itself problem, must look for the reason from the back end! But nginx all these mistakes in their own body, really let Nginx promoter is questioned, after all, from the word understanding, bad gateway? Is it bad nginx? Let the people who do not understand, will directly put the responsibility on the Nginx body, Hope Nginx the next version will be a little bit more friendly error tips, at least not a simple one now 502 bad Gateway, in addition, also do not forget to attach their name.
trigger conditions for Nginx 502
The most common occurrence of 502 errors is the back-end host machine. There is a configuration in the upstream configuration: Proxy_next_upstream, which specifies that Nginx will go to the next back-end host when it encounters data from a back-end host, which is written with 502 of all cases pulled, default is error Timeout Error is when the machine, disconnection and so on, timeout is read blocking timeout, more easily understood. I usually write all of them:
Copy Code code as follows:
Proxy_next_upstream Error timeout invalid_header http_500 http_503;
But now maybe I'm going to get rid of http_500, http_500 specifies that the backend returns a 500 error to a host, the back-end JSP error, would have printed a bunch of stacktrace error messages, is now replaced by 502. But the company's programmers do not think so, they believe that the nginx error, I really do not have the time to explain the principle of 502 ...
503 error can be retained, because the back end is usually Apache resin, if the Apache panic is error, but resin panic, is only 503, so it is necessary to retain.
Solutions
If you encounter 502 problems, you can take the following two steps as a priority.
1, see the current number of PHP fastcgi process is sufficient:
Copy Code code as follows:
Netstat-anpo | grep "php-cgi" | Wc-l
If the actual number of "fastcgi processes" is close to the preset "fastcgi process", then the "fastcgi process count" is not sufficient and needs to be increased.
2, some of the PHP program execution time than the Nginx wait time, you can appropriately increase the nginx.conf configuration file fastcgi timeout time, such as:
Copy Code code as follows:
HTTP {
Fastcgi_connect_timeout 300;
Fastcgi_send_timeout 300;
Fastcgi_read_timeout 300;
......
}
......
PHP.ini Memory_limit set low will be wrong, modified php.ini memory_limit 64M, restart Nginx, found good, the original is the memory of PHP is not enough.
If you do not solve the problem with this modification, you can refer to the following scenarios:
I. Max-children and max-requests
A server running Nginx PHP (FPM) XCache, the average daily traffic around 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. This situation only lasts a few seconds to recover.
Check the PHP-FPM log file to find some clues.
Copy Code code as follows:
Sep 08:32:23.289973 [NOTICE] Fpm_unix_init_main (), line 271:getrlimit (nofile): max:51200, cur:51200 Sep 30 08:32:23.29 0212 [NOTICE] Fpm_sockets_init_main (), Line 371:using inherited socket fd=10, 127.0.0.1:9000″sep 08:32:23.290342 [NO TICE] Fpm_event_init_main (), line 109:libevent:using epoll Sep 08:32:23.296426 [NOTICE] Fpm_init (), line 47:FPM is R unning, PID 30587
In front of these sentences, there are more than 1000 lines 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, increasing the number of children and setting max_requests to 0 or a larger value:
Open/usr/local/php/etc/php-fpm.conf The following two parameters (according to the actual server, too large or not)
Copy Code code as follows:
<value name= "Max_children" >5120</value> <value name= "Max_requests" >600</value>
Then restart the php-fpm.
second, increase the size of buffer capacity
Open the Nginx error log and discover the "Pstream sent too big header while reading response header from upstream". Looked at the data, to the effect that the nginx buffer has a bug caused by the page consumption of our site may be too large. Reference to the foreigner wrote the modification method increases the buffer capacity size setting, 502 problem thoroughly solves. The system administrator then adjusted the parameters to retain only 2 set parameters: Client head buffer,fastcgi buffer size.
Third, Request_terminate_timeout
If it's mostly in the case of post or database operations, rather than being common in static page operations, you can look at one of the php-fpm.conf settings:
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. The problem was solved, and there was no error in the execution for a long time. Optimize the fastcgi, can also change this value 5s to see the effect.
There are 502 errors in php-cgi processes, long PHP execution time, or php-cgi process death.
