一次nginx引起的线上502故障

今天突然接到某PM的求救,说微信支付到应用的请求一直返回502,于是初步了解完情况后,就进入了问题排查阶段。

nginx verison 1.10.2

1,查看Nginx error.log,异常信息为

upstream prematurely closed connection while reading response header from upstream
从上游读取响应头时,上游提前关闭连接

根据日志信息初步判断为nginx在等待tomcat响应时,关闭了连接。导致此问题出现的原因,初步猜测为请求超时或返回响应体过载!

2,排查应用是否正常,验证方式:浏览器直接访问验证。结果:【正常

3,排查Nginx到应用服务器目标端口网略是否正常,验证方式:从Nginx服务器telnet 应用服务器ip和端口。结果:【正常

通过这两步排查,排除了应用故障及网络故障。那么开始验证是否是请求超时!

4,修改Nginx nginx.conf ,在对应的映射位置加入如下参数:

#表示与后端服务器连接的超时时间,即发起握手等候响应的超时时间。一般建议不要超过75s,默认时间60s。
 proxy_connect_timeout 90;
 #表示后端服务器的数据回传时间,即在规定时间之内后端服务器必须传完所有的数据,否则,Nginx将断开这个连接。默认时间60s。 proxy_send_timeout 90; #设置Nginx从代理的后端服务器获取信息的时间,表示连接建立成功后,Nginx等待后端服务器的响应时间,其实是Nginx已经进入后端的排队之中等候处理的时间。默认时间60s。 proxy_read_timeout 90;

再重启执行 nginx -s reload 后,依然不行不管用,感觉到之前的猜测有一点打脸,顿时心里一万只羊驼跑过。不过还好,咱还有第二个猜测啊,那就是返回响应体过载。最后的一根稻草,给点面子呀~!

于是乎,在nginx.conf 的添加如下参数:

#设置缓冲区大小,默认该缓冲区大小等于指令proxy_buffers设置的大小。
 proxy_buffer_size 4k; #设置缓冲区的数量和大小。Nginx从代理的后端服务器获取的响应信息,会放置到缓冲区。 proxy_buffers 4 32k; #用于设置系统很忙时可以使用的 proxy_buffers 大小, 官方推荐的大小为 proxy_buffers*2。 proxy_busy_buffers_size 64k;

重启完nginx后,啪啪打脸~!难道是修改的值不够大?于是把每个数值都乘以100倍~!果然!不!管!用!此时已经怀疑人生了!

emmm,上网查资料,90%的跟老夫的猜测都是一致的!解决方案也是一致的。为毛到我这不好使呢?omg!wtf!

在经过3个小时的绝望后,就去吃饭了。没想到吧,哈哈,哥不陪你玩了(开玩笑)!吃完饭后,突然意识到一个问题,就是!吃饱了脑子就好使了!说正题,tomcat默认采用的协议为 HTTP/1.1,而nginx默认用的是 HTTP/1.0。而HTTP/1.0是不支持keepalive,这样就不能保持活跃连接了啊~!

在酒足饭饱后的第三次猜测,会不会再次打脸呢?答案是肯定是好用的。

答案揭晓时刻:

proxy_http_version 1.1; proxy_set_header Connection "";

Nginx默认使用HTTP1.0从后端获取响应返还给客户端,但是HTTP/1.0不支持keepalive,因此需要配置proxy_http_version 1.1proxy_set_header Connection默认close:通知后端服务器主动关闭连接,这样会导致任何一个客户端的请求都在后端服务器上产生了一个TIME-WAIT状态的连接。

问题成功解决!突然发现羊驼也是很可爱的!

一次nginx引起的线上502故障

 

  • 一次nginx引起的线上502故障已关闭评论
  • 153 views
  • A+
所属分类:未分类
avatar