113资讯网——NGINX 502 Bad Gateway——解决方案
Posted 113p
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了113资讯网——NGINX 502 Bad Gateway——解决方案相关的知识,希望对你有一定的参考价值。
nginx 502 Bad Gateway错误出现的原因较多,对于后端连接php服务的场景下,常见的原因有php服务响应超时,php进程不足等引起的一类服务器错误。
发生原因:
- PHP FastCGI的内存不够用:
当nginx返回静态页面时,这个问题一般不会出现,因为nginx不需要php cgi的处理而直接返回静态页面。但是当网页需要处理大量的php复杂操作的时候,例如执行api采集,或者采集页面的时候,那对php的要求是相当高的,如果配置给他的内存太少,那很容易就会导致php崩溃。 - max-children和max-requests:
主机上运行着nginx php(fpm) xcache的话,访问量日均 10000+ pv左右。如果是近期出现php页面打开很慢,cpu使用率突然降至很低,系统负载突然升至很高,查看网卡的流量,也会发现突然降到了很低这样的情况,而且这种情况只持续数秒钟就恢复,这时检查php-fpm的日志文件发现了一些线索:- 1.Sep 30 08:32:23.289973 [NOTICE] fpm_unix_init_main(), line 271: getrlimit(nofile): max:51200, cur:51200
- 2.Sep 30 08:32:23.290212 [NOTICE] fpm_sockets_init_main(), line 371: using inherited socket fd=10, “127.0.0.1:9000″
- 3.Sep 30 08:32:23.290342 [NOTICE] fpm_event_init_main(), line 109: libevent: using epoll
- 4.Sep 30 08:32:23.296426 [NOTICE] fpm_init(), line 47: fpm is running, pid 30587
看显示的这几句的前面,是1000多行的关闭children和开启children的日志。因为php-fpm有一个参数 max_requests,该参数指明每个children最多处理多少个请求后便会被关闭,默认的设置是500。因为php是把请求轮询给每个children,在大流量下,每个childre到达max_requests所用的时间都差不多,这样就造成所有的children基本上在同一时间被关闭。
在这期间,nginx无法将php文件转交给php-fpm处理,所以cpu会降至很低,不用处理php,更不用执行sql,而负载会升至很高,关闭和开启children、nginx等待php-fpm,网卡流量也降至很低,nginx无法生成数据传输给客户端。
解决方式很简单,就是增加children的数量,并且将 max_requests 设置未 0 或者一个比较大的值,打开 /usr/local/php/etc/php-fpm.conf,调大以下两个参数,但是要根据主机实际情况,数值过大也不行。
- <value name=”max_children”>5120</value>
- <value name=”max_requests”>600</value>
- 在开启opcache的情况下,如果出现502错误,则是由于版本导致的问题:
如果还在用php5版本建议升级php7,如果代码不支持php7,建议更换程序与模板文件! - PHP FastCGI进程数不够用:
当网站并发访问巨大时,php fastcgi的进程不一定能响应所有的访问,因为cgi是单线程多进程工作的,也就是说cgi需要处理完一个页面后再继续下一个页面。如果进程数不够,cgi按排队处理之前的请求,队列满之后的请求只有被放弃。这个时候nginx就会不时的出现502错误。这种情况下,开启Nginx的错误日志可以很清晰的看见相应的报错,例如”all backends could not serve”。 - (文章原文:https://www.113p.cn/231.html)
- PHP FastCGI的内存不够用:
以上是关于113资讯网——NGINX 502 Bad Gateway——解决方案的主要内容,如果未能解决你的问题,请参考以下文章
nginx 反向代理 Nginx 502 Bad Gateway
调试 502 Bad Gateway 错误 - Ubuntu、Nginx、Unicorn