接口间断性504分析(一) 有更新!

  |   0 评论   |   3,188 浏览

刚进新公司就遇到一个很棘手的问题:线上一个接口每天0.5%左右的概率会出现504,出现的时机也是随机的,每天大概有一到两个时间点会触发,非常诡异。

API请求路径如下图所示,haproxy做为网关,后端接两个server,client通过haproxy来访问server端的服务:
imagepng

首先开始去查haproxy的日志,如下图所示,注意到第1行中的504,以及前面的12000ms,说明server端返回超时了,haproxy超时时间为2分钟:
imagepng

再看server端的日志,没有发现504对应的请求,最长的响应时间也不超过15秒,为什么haproxy会超时120秒呢?再去查haproxy的日志发现存在504的接口不止一个。
imagepng

于是怀疑是不是haproxy主动断掉,再仔细检查日志,发现存在sH的标识,以下是对应的解释:

sH   
#服务器可以返回其响应头之前的“超时服务器”冲突。 
#这是最常见的异常,表示太长的事务,可能是由服务器或数据库饱和引起的。 
#立即的解决方法是增加“超时服务器”设置,但请务必记住,用户体验将遭受这些长时间的响应。 
#唯一的长期解决方案是修复应用程序。  
#参考:https://blog.csdn.net/chengfei112233/article/details/78983041

这就否定了haproxy本身的问题,haproxy确实是等了120秒,server没有响应。

那是不是server端出现了什么问题,导致不能返回给haproxy正确的响应呢?server的应用日志里没有现象,接下来就可以充分怀疑tcp本身的机制导致的响应丢弃,网上搜索了下,发现这个参数tcp_tw_recycle与tcp_timestamps这两个参数同时开启时,在NAT环境会出现连接失败的情况。
(60秒内,连接两个相同的请求(四元组一致:源IP/端口+目标IP/端口),后一个时间戳的请求,会被忽略。缓存每个连接最新的时间戳,后续请求中如果时间戳小于缓存的时间戳,即视为无效,相应的数据包会被丢弃。)

那我们是不是也是这样的原因呢?查了下参数确实都配置了,并且也netstat存在reject的日志,确实跟这个问题很像。与领导沟通了下,觉得这个问题最好还是抓包确认下,不能盲目参照别人经验。于是接下来开始了抓包之旅。
imagepng

抓包下来,分析却发现TCP连接是没问题的,TCP包序列并没有发现参数导致的大量异常序列(TCP Retransmission),但是应用就是没有返回,真的是非常诡异。
imagepng

再去分析应用截取日志,通过IP与端口对应到请求:
imagepng

从上面两张图可以清楚的看到:haproxy断开连接后,应用才收到请求,非常诡异。

从以上对网络层面的分析,能推断出centos在TCP握手后,没有将后续的请求推送到应用。但是接下来怎么排查,真的是一点思路都没有。但是问题仍然存在,分析不能停止,于是向运维申请了一些服务器监控的权限,试图从zabbix上再找到些蛛丝马迹。结果仍然没有收获。

这时候怀疑是不是服务器性能比较差,压力抗不住,因为只有其中一台配置比较差的504的情况很多,而且每天可能就一到两个时间点会爆发。于是将haproxy的负载又做了调整,调整成了8:2,将504的那台服务器的比例调整低了。

观察了一周时间,并没有发现504有任何明显的降低,这充分说明并非负载导致的504。而且发现一个现象,当问题出现后,明显发现linux的剩余内存少了非常多,只有大概几十M。

初步怀疑存在内存泄露,但是JVM并没有错误迹象,并且检查gc日志都是正常的,非常奇怪。最终,向运维申请加了一台服务器,三台服务器的比例调整成6:2:2,观察了一周,发现504仍然存在,但是只会出现在那台一直报504的机器上。再观察一段时间,会把504多的那台设备下掉。

下面是三台机器的内存情况:

imagepng
imagepng
imagepng

明显发现最上面一台可用内存很少,504到此为止算是解决了。

总结一下,针对间断性504的异常问题,分别从网络、日志、监控、参数、命令等多个途径寻找异常点,来确定问题产生原因。最终结论是系统剩余内存太小,导致网络请求一直停留在系统层面,没有到达应用,超过了haproxy的超时限制。

其实还是走了一些弯路的,一开始就怀疑过内存,但是这个结论难以令人信服,所以先排除应用本身的问题后,才推动资源去通过替换服务器的方式解决该问题。

2018-12-25 续:
真的解决了么?其实并没有,真正的原因在下一篇总结。



---------------------------
本站文章除注明转载外,均为本站原创或编译。欢迎任何形式的转载,但请务必注明出处,尊重他人劳动。
转载请注明:文章转载自 xiajl.cn

评论

发表评论