欢迎来到云服务器

服务器租用

Nginx 502错误发生原因与办理步伐总结

一些运行在Nginx上的网站有时候会呈现“502 Bad Gateway”错误,有些时候甚至频繁的呈现。有些站长是在方才转移到Nginx之后就呈现了这个问题,所以常常会猜疑这是不是Nginx的问题,但事实上这是个误区。

以下是从张宴和Ayou的博客汇集整理的一些Nginx 502错误的排查要领,供各人参考:

Nginx 502错误的原因较量多,是因为在署理模式下后端处事器呈现问题引起的。这些错误一般都不是nginx自己的问题,必然要从后端找原因!但nginx把这些堕落都揽在本身身上了,着实让nginx的推广者备受置疑,究竟从字眼上领略,bad gateway?不就是bad nginx吗?让不相识的人看到,会直接把责任推在nginx身上,但愿nginx下一个版本会把堕落提示写稍微友好一些,至少不会是此刻简朴的一句502 Bad Gateway,别的还不忘附上本身的台甫。

Nginx 502的触发条件

502错误最凡是的呈现环境就是后端主机当机。在upstream设置里有这么一项设置:proxy_next_upstream,这个设置指定了nginx在从一个后端主机取数据碰着何种错误时会转到下一个后端主机,里头写上的就是会呈现502的所有环境拉,默认是error timeout。error就是当机、断线之类的,timeout就是读取堵塞超时,较量容易领略。我一般是全写上的:



proxy_next_upstream error timeout invalid_header http_500 http_503;

不外此刻大概我要去掉http_500这一项了,http_500指定后端返回500错误时会转一个主机,后端的jsp堕落的话,原来会打印一堆stacktrace的错误信息,此刻被502代替了。但公司的措施员可不这么认为,香港云服务器 美国云主机,他们认定是nginx呈现了错误,我实在没空跟他们表明502的道理了……

503错误就可以保存,因为后端凡是是apache resin,假如apache死机就是error,但resin死机,仅仅是503,所以照旧有须要保存的。

办理步伐

碰着502问题,可以优先思量凭据以下两个步调去办理。

1、查察当前的PHP FastCGI历程数是否够用:



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

假如实际利用的“FastCGI历程数”靠近预设的“FastCGI历程数”,那么,说明“FastCGI历程数”不足用,需要增大。

2、部门PHP措施的执行时间高出了Nginx的期待时间,可以适当增加nginx.conf设置文件中FastCGI的timeout时间,譬喻:



......
http
{
......
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
......
}
......

php.ini中memory_limit设低了会堕落,修改了php.ini的memory_limit为64M,重启nginx,发明好了,本来是PHP的内存不敷了。

假如这样修改了还办理不了问题,可以参考下面这些方案

一、max-children和max-requests

一台处事器上运行着nginx php(fpm) xcache,会见量日均 300W pv阁下

最近常常会呈现这样的环境: php页面打开很慢,cpu利用率溘然降至很低,系统负载溘然升至很高,查察网卡的流量,也会发明溘然降到了很低。这种环境只一连数秒钟就规复了

查抄php-fpm的日志文件发明白一些线索



Sep 30 08:32:23.289973 [NOTICE] fpm_unix_init_main(), line 271: getrlimit(nofile): max:51200, cur:51200
Sep 30 08:32:23.290212 [NOTICE] fpm_sockets_init_main(), line 371: using inherited socket fd=10, “127.0.0.1:9000″
Sep 30 08:32:23.290342 [NOTICE] fpm_event_init_main(), line 109: libevent: using epoll
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

腾讯云代理

Copyright © 2003-2021 MFISP.COM. 国外vps服务器租用 梦飞云服务器租用 版权所有 粤ICP备11019662号