Nginx 502/504 Gateway time-out error perfect solution "forward"

After the installation of Nginx+php-fpm+mysql, the application of running PHP will often appear 504 gateway time-out or 502 bad gateway situation.

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. This situation may be due to the Nginx default fastcgi process response buffer is too small, which will cause the fastcgi process to be suspended, if your fastcgi service is not good for this suspend processing, then it is very likely to lead to 504 Gateway time-out 。

In general, this situation may be due to the Nginx default fastcgi process response buffer is too small, which will cause the fastcgi process to be suspended, if your fastcgi service is not good for this suspend processing, then it is very likely to cause 504 Gateway Time-out
Now the site, especially some forums have a lot of replies and a lot of content, a page even has hundreds of K
The default fastcgi process response buffer is 8K, we can set the large point

In nginx.conf, join:

Fastcgi_buffers 8 128k

This means that the fastcgi buffer is set to 8x128k
Of course, if you are doing an immediate operation, you may need to make the Nginx timeout parameter larger, for example, set to 60 seconds:

Send_timeout 60;

I just adjusted the two parameters, the result is no longer show that timeout, can say the effect is good

This problem delayed me almost 4 hours of time, online there are many predecessors of the solution, here to record the way to solve the problem. The first problem is that PHP's script execution time is too long and has exceeded the bottom line that Nginx can accept .

In the Nginx log, you will see this log

2012/08/11 13:39:45 [ERROR] 30788#0: * Upstream timed out (110:connection timed out)

While reading response headers from upstream, client:127.0.0.1, server:www.cr173.com

Request: "get/http/1.1", Upstream: "fastcgi://127.0.0.1:9000", Host: "Www.cr173.com

This log will be found in the logs of PHP-FPM.

2012/08/11 13:39:45 [ERROR] 30788#0: * Upstream timed out (110:connection timed out)

While reading response headers from upstream, client:127.0.0.1, server:www.cr173.com

Request: "get/http/1.1", Upstream: "fastcgi://127.0.0.1:9000", Host: "Www.cr173.com"

In general, this occurs because Nginx will read the results of the fastcgi from the PHP-FPM 9000 port, and so on, and so on for n long no reply, so reported 504. The workaround is simple, modify the maximum execution time for PHP

; Maximum execution time of each script, in seconds; Http://php.net/max-execution-time;

Note:this directive is hardcoded-0 for the CLI SAPI;

Fix by Matt 2012.8.11

; max_execution_time = 3000

Here I comment out the time limit of the php.ini parameter. and the PHP-FPM.

; request_terminate_timeout = 0

This parameter will be max_execution_time in php.ini for some reason not working properly.

Previously set is 300s, the installation of Magento has been reported 504. It was then modified to 3000. Add the config file in Nginx

#add by Matt 2012.8.11

Fastcgi_read_timeout 3000;

Fastcgi_connect_timeout 3000;

Fastcgi_send_timeout 3000;

Magento How many SQL files do you install?

PS: Sometimes the cache is too small will cause 504, the specific situation also needs to be based on Nginx log content to analyze. To modify the fastcgi cache size:

Fastcgi_buffers 2 256k;

Fastcgi_buffer_size 128k;

Fastcgi_busy_buffers_size 256k;

Fastcgi_temp_file_write_size 256k;

VPS appears nginx 504 Gateway time-out error

CC only to nginx.conf and php-fpm.conf two configuration files made some changes, observe a period of time, look at the effect.

1. Set the corresponding parameters in the nginx.conf configuration file to the following:

Command: Vi/usr/local/nginx/conf/nginx.conf (lnmp.org produced by the LNMP one-click installation package path, others please find their own directory)

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;

2. Set the corresponding parameter in the php-fpm.conf configuration file to the following values:

Command: Vi/usr/local/php/etc/php-fpm.conf (lnmp.org produced by the LNMP one-click installation package path, others please find their own directory)

<value name= "Max_children" >9</value> (CC purchased VPS memory is small so can not be set too large, should be based on your memory to set)

<value name= "Request_terminate_timeout" >600s</value> (depending on the circumstances, please refer to the reference article for details)

<value name= "Style" >apache-like </value> (the default static processing of PHP-FPM causes the php-cgi process to consume memory for a long time and cannot be released, which is one of the reasons for Nginx error, The php-fpm can therefore be changed to Apache mode. ）

To Linux CC is also a rookie, have to follow other people's method to set up, wait a while, no problem, this method should be a very effective method.

The implication of Nginx 502 Bad Gateway is that the requested php-cgi has been executed, but the php-cgi process is terminated for some reason (generally, the problem of reading the resource) is not completed.

Error troubleshooting:

1. See if the fastcgi process is started

2. Check the operation of the FASTCGI process in the system

A 502 error can occur when the number of fastcgi processes in the system is insufficient, the PHP execution time is long, or the php-cgi process dies.

First look at the number of processes on the system that are fastcgi open

PS aux | grep "php-cgi" | Wc-l

See how many php-cgi to handle a request

Netstat-anpo | grep "php-cgi" | Grep-v "grep" | Wc-l

If the number of processes that are processing the request is close to the open process, the number of worker processes is configured too small to modify the php-fpm.conf to increase the number of processes in PHP

3, fastcgi execution time is too long

You can adjust the following parameters in nginx.conf according to the actual situation:

Fastcgi_connect_timeout 300;
Fastcgi_send_timeout 300;
Fastcgi_read_timeout 300;

increased the corresponding request time for fastcgi. But I encountered this problem in practice, set to 500, or will appear, just 120 less than when I set. Later found mainly in some post or database operation when this situation occurs, static pages will not appear.
Repeatedly check the problem, debugging, also increased the number of CGI process.
128
256 plus go may become very slow. It takes up a lot of memory.
There is one more item in the PHP-FPM.CONF setting, which may not have been noticed at the time and inadvertently changed the value.
Request_terminate_timeout
This value is Max_execution_time, which is the fast-cgi execution script time.
0s
0s is closed, is infinite execution goes on. (I changed a number when I did not look closely at the time of loading)
found that the problem solved, the execution for a long time will not be wrong
Optimize the fastcgi, you can also change the value of 5s. Look at the effect

4, the head is too big

Nginx, like Apache, has a buffer limit of the previous period, you can adjust the buffering parameters

Fastcgi_buffer_size 32k;
Fastcgi_buffers 8 32k;

If you are using Nginx load balancer proxying, adjust the
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, will be nginx error log open, found "Pstream sent too big header while reading response headers from upstream" Such error prompts, look up information, the effect is nginx slow There is a bug in the Flushing area, the page consumption of our website may be too large. Refer to the modification method written by the foreigner increased the size of the buffer capacity setting, 502 problem solved completely, and then the system administrator to adjust the parameters only retained 2 settings parameters: Client head buffer,fastcgi buffer size.

Http://blog.rackcorp.com/?p=14

7, a server running nginx PHP (FPM) XCache, the average number of visits around 300W PV

Recently, this is often the case: PHP page Open very slow, the CPU usage suddenly dropped to very low, the system load suddenly up to very high, look at the network card traffic, will also find suddenly dropped to very low. This condition only lasts a few seconds to recover the
Check php-fpm log file found 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 Socke T fd=10,
Sep 08:32:23.290342 [NOTICE] Fpm_event_init_main (), line 109:libevent:using epoll
Sep 30 08:32:23.2964 [NOTICE] Fpm_init (), line 47:FPM is running, PID 30587
in front of these sentences, is more than 1000 lines of closed children and open children log  ?
Originally, PHP-FPM has a parameter max_requests, which indicates how many requests per children will be closed and the default setting is 500. Because PHP is polling the request to each children, it takes about the same amount of time for each childre to reach max_requests at large traffic, which causes all children to be shut down essentially at the same moment.
During this time, Nginx can not transfer php files to PHP-FPM processing, so the CPU will be reduced to very low (no processing PHP, not the execution of SQL), and the load will rise to very high (close and open children, nginx wait php-fpm), Network card traffic is also reduced to very low (Nginx cannot generate data transfer to the client)
to solve the problem is simple, increase the number of children, and set max_requests not 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 actually need to think comprehensively, in general Nginx 502 Bad Gateway and php-fpm.conf settings, and Nginx 504 Gateway time-out is related to the nginx.conf settings.

The correct setting takes 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 most important setting here is the first three, which is

Fastcgi_connect_timeout 300s;

Fastcgi_send_timeout 300s;

Fastcgi_read_timeout 300s;

This specifies the php-cgi connection, send and read time, 300 seconds is sufficient, so my server rarely appears 504 Gateway time-out this error. The most critical is the php-fpm.conf setting, which will lead directly to 502 bad Gateway and 504 Gateway time-out.

Let's take a closer look at some important parameters of php-fpm.conf:

Php-fpm.conf has two key 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 generic, but it needs to be calculated by itself.

The method is calculated as follows:

If your server performance is good enough, and the broadband resources are sufficient, PHP scripts do not have loops or bugs, you can set the "request_terminate_timeout" directly to 0s. The meaning of 0s is to let php-cgi go on without time limit. And if you can't do this, that means your php-cgi may have a bug, or your broadband is not enough or other causes your php-cgi to be able to feign death then it is recommended that you assign a value to "Request_terminate_timeout". This value can be set based on the performance of your server. Generally, the better the performance, the higher you can set, 20 minutes-30 minutes. Because my server PHP script needs to run for a long time, some may be more than 10 minutes so I set 900 seconds, so that does not cause php-cgi dead and 502 bad gateway this error.

And how does the value of "Max_children" be calculated? This value is in principle the bigger the better, the php-cgi process will be processed very quickly, the queue of requests will be very small. Setting "Max_children" also needs to be based on the performance of the server, in general, a server normally consumes about 20M of memory per php-cgi, so my "Max_children" I set to 40, 20m*40= 800M means that at peak time all php-cgi are within 800M, below my valid memory 1Gb. And if my "Max_children" set the smaller, such as 5-10, then php-cgi will be "very tired", processing speed is also very slow, waiting for a longer time. If the request has not been processed for a long time, the 504 Gateway time-out this error, while the very tired of the php-cgi are dealing with the problem will appear 502 Bad Gateway this error.

Reproduced original address:

Nginx 504 Gateway Time-out Error Perfect solution _ cc software Information
Http://www.cr173.com/html/50534_1.html

And

Http://www.server110.com/nginx/201401/5032.html

Nginx 502/504 Gateway time-out error perfect solution "forward"