专栏首页行者悟空一次nginx引起的线上502故障

一次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状态的连接。

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

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 一个switch case引起的线上故障

    1、上午的时候,QA同学突然说,测试自动化的流程突然过不去了,问我是不是最近对线上做了某些修改。当时第一反应是不可能

    高性能架构探索
  • 一次线程池引发的线上故障分析

    线上监控到大量接口报错,定位到异常机器,将异常机器隔离后,线上服务恢复正常。拿到业务报错日志如下:

    有赞coder
  • teg 一次云故障引起的思考

    很多朋友经历了昨晚阿里云3小时左右的故障,我司的业务也受到了一定影响,技术的同事一起熬夜奋战,最终观察服务稳定运行了两个多小时,直到凌晨五六点多才逐渐登出VPN...

    葫芦
  • 让研发人员紧张的这条“故障神经线”

    在众多HTTP CODE 里,作为一名程序员我们都喜欢200,但从不喜欢以5xx打头的HTTP返回码,比如502,注意不是520。发生大量502报警,你会不会紧...

    用户2781897
  • 让研发人员紧张的这条“故障神经线”(上)

    在众多HTTP CODE 里,作为一名程序员我们都喜欢200,但从不喜欢以5xx打头的HTTP返回码,比如502,注意不是520。发生大量502报警,你会不会紧...

    王新栋
  • Nginx+FPM结构模型剖析及优化

    随着php脚本语言使用的普及,目前webserice服务大部分都在用nginx+(php-fpm)的结构,了解了其工作过程后才可以在各个方面想办法做调整优化和故...

    小小科
  • 记一次线上kafka一直rebalance故障

    这个错误的意思是,消费者在处理完一批poll的消息后,在同步提交偏移量给broker时报的错。初步分析日志是由于当前消费者线程消费的分区已经被broker给回收...

    大数据技术与架构
  • Linux: Nginx proxy_pass域名解析引发的故障

    部署细节:   两容器均部署在同一机器上,通过 docker-compose 编排,并且通过link方式链接。

    Lin_R
  • 记一次线上DPDK-LVS的故障排查

    http://doc.dpdk.org/guides/prog_guide/mbuf_lib.html

    迅达集团

扫码关注云+社区

领取腾讯云代金券