499 Error Resolution
What is the 499 error? Let's look at the definition of Nginx in the source code:
Ngx_string (Ngx_http_error_495_page),/*495, HTTPS certificate error*/ngx_string (ngx_http_error_496_page),/*496, HTTPS no certificate*/ngx_string (ngx_http_error_497_page),/*497, http to HTTPS*/ngx_string (ngx_http_error_404_page),/*498, Canceled*/ngx_null_string,/*499, client has closed connection*/
As you can see, 499 corresponds to "client has closed connection". This is most likely because the server-side processing time is too long, the client "impatient".
"The client has shut down the connection", or "Connection timed out" , no matter how many times you set the time-out is no longer the PHP process is not enough to improve the number of PHP processes to solve the default test environment to open 5 sub-processes
502 and 504 Error Solutions
First, the error message description:
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.
The implication of Nginx 504 Gateway time-out is that the requested gateway does not receive a timely response
Second, the cause of error analysis:
To solve these two problems is actually need to think comprehensively, in general, Nginx 502 Bad Gateway and php-fpm.conf settings,
The Nginx 504 Gateway time-out is related to the nginx.conf setting.
Php-fpm.conf has two key parameters, one is "Max_children" and the other is "request_terminate_timeout", but this value is not universal, 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 is much faster, the queue 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.
Iii. Temporary Solutions:
In summary, Nginx hints 502 and 504 for the temporary solution of the error is:
1, adjust the relevant settings php-fpm.conf:
Max_children 32;
Request_terminate_timeout 30s;
Request_terminate_timeout sets the time-out for a single request to expire. You should also note the Max_execution_time parameter in php.ini. The 502 error also occurs when the request is terminated.
2, adjust the relevant settings nginx.conf:
Fastcgi_connect_timeout 600;
Fastcgi_send_timeout 600;
Fastcgi_read_timeout 600;
Fastcgi_buffer_size 256k;
Fastcgi_buffers 256k;
Fastcgi_busy_buffers_size 512k;
Fastcgi_temp_file_write_size 512k;
Iv. Final Level solutions:
The solution shown in Heading 3 only solves the problem temporarily, and if the site's traffic is really very large, and the nginx+fastcgi can only have a good effect on dealing with high concurrency in a moment or a short period of time, the only ultimate solution at the moment is a timed smooth restart php-cgi.
The specific configuration is as follows:
1. Write a very simple script:
#vi/home/www/scripts/php-fpm.sh
The contents are as follows:
#!/bin/bash
# This script run at */1
/USR/LOCAL/PHP/SBIN/PHP-FPM Reload
2. Add the script to the scheduled task:
#crontab-E
The contents are as follows:
*/1 * * * */home/www/scripts/php-fpm.sh
Note: For the sake of brevity, it is also possible to write the PHP-FPM Smooth restart command directly in the crontab without writing a script.
nginx502,504 and 499 Error Solutions