前言:
最近发生过几次线上服务出现不能接收任何请求的情况,造成了较大的影响。该种情况一般称之为Tomcat假死,在发生的几次中进行排查也总结了一些经验。
背景描述:
项目在运行过程中,突然无法处理新的请求。原来的tps都是几千几万,突然间所有机器都变为0了,对线上业务影响极大!于是立即查看服务运行状况,但是还是在running中,于是可以认为是tomcat假死。Tomcat假死排查思路讲解:
造成tomcat无法继续进行业务处理的情况有很多,所以需要多方面的进行一一排查。
1.首先检查服务运行情况,判定业务无法处理的表面原因,是否为tomcat假死。
2.查看项目日志,排查是否有明显的错误情况,针对错误情况处理。
3.若项目本身无法判断问题所在,则需要对服务所在机器的网络、磁盘、CPU等进行逐一排查。
4.针对tomcat假死情况,基本由于网络上的阻塞造成的,所以优先考虑查看网络情况。
5.首先,确定请求入口是否正常,排除外部原因。
6.第二步,查看服务对应的端口的情况。使用命令netstat -anp |grep 端口号,可以查看该端口详细的情况,如下,有协议类型、源ip+port、tcp协议状态等信息,这里主要关注tcp协议的连接数量和每条连接对应的状态。
netstat -an |grep 80
tcp4 0 0 192.168.31.24.51380 120.253.255.102.443 ESTABLISHED
tcp4 0 0 192.168.31.24.50935 192.30.71.80.443 ESTABLISHED
tcp4 31 0 192.168.31.24.50863 3.80.20.154.443 CLOSE_WAIT
tcp6 0 0 fe80::b7ca:330b:.1028 fe80::5059:ee74:.1025 ESTABLISHED
tcp6 0 0 fe80::b7ca:330b:.1024 fe80::5059:ee74:.1024 ESTABLISHED
还可以通过grep具体的tcp状态码来确定当前tcp端口的连接数量及情况。
netstat -an |grep 80 |grep CLOSE_WAIT
tcp4 31 0 192.168.31.24.50863 3.80.20.154.443 CLOSE_WAIT
tcp4 31 0 192.168.31.24.50855 3.80.20.154.443 CLOSE_WAIT
tcp4 31 0 192.168.31.24.50854 3.80.20.154.443 CLOSE_WAIT
tcp4 31 0 192.168.31.24.50853 3.80.20.154.443 CLOSE_WAIT
tcp4 31 0 192.168.31.24.50852 3.80.20.154.443 CLOSE_WAIT
除此之外,还可以使用 ss -lnr |grep 80,确定对应端口的Send-Q和Recv-Q数量。一样可以反应对应端口的tcp是否阻塞。
7.第三步,根据上一步查看服务端口的tcp情况,确定最终问题是由于tcp连接没有正确释放,导致端口的TCP连接队列打满,后续请求无法进入连接队列而造成Tomcat假死!
8.最后,确定问题后,去服务中寻找原因。可能由于对应的http请求没有进行Response,或者由于服务处理速度远不及请求的数量,导致连接队列在运行中慢慢被打满。
解决方案:
1.碰到该类情况,首先可以尝试进行服务的重启,可能可以继续支持服务,一定时间后服务会进入假死;同时在业务前侧进行关闭,减少甚至关闭请求量。使业务的损失降低到最小。
2.回退版本,一般问题的出现都是由新业务上线造成的,先回退无问题版本。
3.针对排查的问题,锁定问题原因,进行针对性解决。
总结:
造成服务假死的现象,基本是由于网络问题。多半是程序中的响应处理异常,或者在高tps系统中使用了耗时的同步操作,导致tps能力下降进而造成假死。合理进行代码的处理,就可以避免和解决服务假死的问题!