周一高高兴兴来上班,突然同事说网关服务G挂了,偶尔正常。
什么,10台服务竟然大部分都挂了,以下是排查步骤:
服务简称G、A,G转发到A,服务器地址简称AIP1、AIP2。。。GIP1、GIP2。。。
1.登到服务器上去,查看端口8000,进程还在,然后curl本地地址,可以连接,尝试其他服务器也都正常;
2.于是联系运维同事查看网络以及负载,发现负载转发到AIP上的nginx,然后由该nginx转发到GIP上的8080端口;
3.竟然不是不是8000端口,是不是搞错了,于是查看GIP服务器上8080端口,也在,这真是好尴尬,同一个应用,竟然在一个服务器启动两个;
4.于是查看8080端口是否可用,还是curl,不可用,查看应用信息:netstat -antp | grep 8080,拿到pidG后查看进程信息netstat -antp | grep pidG,好多CLOSE_WAIT的socket连接;
5. 由于是生产问题,先将pidG的信息保存下来,然后dump下堆信息:jmap -dump:live,format=b,file=heap.bin <pid>,迅速重启应用,客户端访问正常;
6.那问题在哪呢,开始怀疑是httpClient有资源没有被关闭导致,简单查了下代码没有发现问题;
7.万能的baidu,查了下,有说可能是tomcat的bug,于是对比生产、测试、以及本地的tomcat代码,发现确实有部分跟网上描述的一致:http://mp.weixin.qq.com/s/ppNIA__uYaEeQ6HOdY8x0Q,在此处查了不少时间;
8.之后想到除了tomcat启动还使用了内嵌的jetty启动,于是查看8000端口是否存在问题,发现是存在的,排除tomcat的问题;
9.继续排查代码,检查各种异常,终于发现有个地方在处理异常时没有判断G中是否有A的响应,而直接给调用方响应,很可能导致A的响应没有被正确关闭,增加这部分关闭代码;
10.部署到测试环境,进行压测10000次,再没发现CLOSE_WAIT状态的socket,ok。
备注:CLOSE_WAIT状态为远端已发送关闭连接信号,等待关闭的socket状态,具体可参见:http://blog.csdn.net/xiaofei0859/article/details/6044567