Home  >  Article  >  Operation and Maintenance  >  What should I do if nginx reports error 502? Solution sharing

What should I do if nginx reports error 502? Solution sharing

青灯夜游
青灯夜游forward
2022-03-04 16:07:538669browse

What should I do if nginx reports error 502? This article will talk about the solution to nginx error 502. I hope it will be helpful to everyone!

What should I do if nginx reports error 502? Solution sharing

http request process: Under normal circumstances, when submitting a dynamic request, nginx will directly transfer the request to php-fpm, and php-fpm will then allocate the php-cgi process to process related requests, and then return in sequence. Finally, nginx feeds the results back to the client browser.

Nginx 502 Bad Gateway error is a problem with FastCGI

Solution

If you encounter 502 problems, you can give priority to following Follow these two steps to solve it.

1. Check whether the current number of PHP FastCGI processes is sufficient (max_children value)

netstat -anpo | grep "php-cgi"| wc -l

If the actual number of "FastCGI processes" used is close to the default "FastCGI "Number of processes", then it means that "Number of FastCGI processes" is not enough and needs to be increased.

2. The execution time of some PHP programs exceeds the waiting time of Nginx (php lacks memory)

Increase the FastCGI timeout time in the nginx.conf configuration file, for example :

memory_limit=64M

in

    fastcgi_connect_timeout 300;
    fastcgi_send_timeout 300;
    fastcgi_read_timeout 300;
php.ini, restart nginx.

If this modification still cannot solve the problem, you can refer to the following solutions:

3, max-children and max-requests

One nginx php (fpm) xcache is running on the server, with an average daily visit volume of about 300W pv

Such a situation often occurs recently: the php page opens very slowly, the cpu usage suddenly drops to a very low level, and the system load suddenly When it rises to a very high level, if you check the traffic of the network card, you will find that it suddenly dropped to a very low level. This situation only lasted for a few seconds and then recovered.

Checking the log file of php-fpm found some clues:

    Sep3008:32:23.289973[NOTICE] fpm_unix_init_main(), line 271: getrlimit(nofile): max:51200,cur:51200
    Sep3008:32:23.290212[NOTICE] fpm_sockets_init_main(), line 371:using inherited socket fd=10,“127.0.0.1:9000″
    Sep3008:32:23.290342[NOTICE] fpm_event_init_main(), line 109: libevent:using epoll
    Sep3008:32:23.296426[NOTICE] fpm_init(), line 47: fpm is running, pid 30587

Before these sentences, there are more than 1,000 lines of closing children and Turn on children's log

It turns out that php-fpm has a parameter max_requests, which specifies the maximum number of requests each child can handle before being closed. The default setting is 500. Because PHP polls requests to each child, under heavy traffic, each child takes about the same amount of time to reach max_requests, which causes all children to be closed basically at the same time.

During this period, nginx cannot transfer the php file to php-fpm for processing, so the cpu will drop to a very low level (no need to process php, let alone execute sql), and the load will rise to a very high level (close and Turn on children, nginx waits for php-fpm), and the network card traffic is also reduced to very low (nginx cannot generate data to transmit to the client)

Increase the number of children, and set max_requests to less than 0 or a relatively large value :

Open/usr/local/php/etc/php-fpm.conf

Adjust the following two parameters (according to the actual situation of the server, too large will not work) )

    5120
    600

Then restart php-fpm.

5. Increase the buffer capacity

Open the nginx error log and find an error message like "pstream sent too big header while reading response header from upstream" . After checking the information, the general idea is that there is a bug in the nginx buffer. The buffer occupied by the page consumption of our website may be too large. Referring to the modification method written by a foreigner, the buffer capacity setting is increased, and the 502 problem is completely solved. Later, the system administrator adjusted the parameters and retained only two setting parameters: client head buffer and fastcgi buffer size.

6. request_terminate_timeout

If 502 occurs mainly during some posts or database operations, rather than common in static page operations, then you can check Check one of the php-fpm.conf settings: request_terminate_timeout

This value is max_execution_time, which is the execution script time of fast-cgi.

0s is closed, which means it will be executed indefinitely. (When I was dressing, I changed a number without looking carefully)

In optimizing fastcgi, you can also change this value for 5 seconds to see the effect.

If the number of php-cgi processes is not enough, the php execution time is long, or the php-cgi process dies, a 502 error will occur.

Extended knowledge:

Nginx 502 Bad Gateway means that the requested PHP-CGI has been executed, but for some reason (usually a problem with reading resources) The PHP-CGI process is terminated due to incomplete execution. Generally speaking, Nginx 502 Bad Gateway is related to the settings of php-fpm.conf.

php-fpm.conf has two crucial parameters, one is max_children and the other is request_terminate_timeout, but this value is not universal and needs to be calculated by yourself. When a 502 problem occurs during installation and use, it is usually because the default php-cgi process is 5. It may be caused by not enough php-cgi processes. You need to modify /usr/local/php/etc/php-fpm.conf Increase the max_children value appropriately.

The calculation method is as follows:

 如果你服务器性能足够好,且宽带资源足够充足,PHP脚本没有系循环或BUG的话你可以直接将 request_terminate_timeout设置成0s。0s的含义是让PHP-CGI一直执行下去而没有时间限制。而如果你做不到这一点,也就 是说你的PHP-CGI可能出现某个BUG,或者你的宽带不够充足或者其他的原因导致你的PHP-CGI假死那么就建议你给 request_terminate_timeout赋一个值,这个值可以根据服务器的性能进行设定。一般来说性能越好你可以设置越高,20分钟-30分 钟都可以。而max_children这个值又是怎么计算出来的呢?这个值原则上是越大越好,php-cgi的进程多了就会处理的很快,排队的请求就会很少。 设置max_children也需要根据服务器的性能进行设定,一般来说一台服务器正常情况下每一个php-cgi所耗费的内存在20M左右

 按照官方的答案,排查了相关的可能,并结合了网友的答案,得出了下面的解决办法。

 1、查看php fastcgi的进程数(max_children值)

netstat -anpo | grep “php-cgi” | wc -l

5(假如显示5)

2、查看当前进程

 top观察fastcgi进程数,假如使用的进程数等于或高于5个,说明需要增加(根据你机器实际状况而定)

 3、调整/usr/local/php/etc/php-fpm.conf 的相关设置

 19b28ecdcb02fd02e7977bafb610285a104b175f9a50d57c75316becd702e959dc46f80ce9d85bf57c6302aebe0e298a8260s4b175f9a50d57c75316becd702e959dcmax_children最多10个进程,按照每个进程20MB内存,最多200MB。request_terminate_timeout执行的时间为60秒,也就是1分钟。

推荐教程:nginx教程

The above is the detailed content of What should I do if nginx reports error 502? Solution sharing. For more information, please follow other related articles on the PHP Chinese website!

Statement:
This article is reproduced at:cnblogs.com. If there is any infringement, please contact admin@php.cn delete