文章目录
- 1、问题描述
-
- 1、情景再现
- 2、排查思路
-
- 1、我们先看一下TCP状态转换图:
- 2、知道了这种状态,那我们分析一下哪些情况会产生这种状态呢:
-
- 1、系统负载高
- 2、程序没有设置超时断开
- 3、查看程序日志分析
- 3、解决办法
-
- 1、第一种情况:
- 2、第二种情况:
- 3、第三种情况:
- 4、临时清理CLOSE_WAIT
-
- 1、找出CLOSE_WAIT
- 2、Kill掉程序ID
1、问题描述 1、情景再现 在阿里云上面的Centos机器上面跑的java程序,突然有人反馈访问特别慢,在接到反馈后,查看机器cpu和内存,所有指标都正常,查看服务占用的8090端口时发现有大量的CLOSE_WAIT。
netstat -anput | grep 8090
netstat -anput | grep 8090 | grep CLOSE_WAIT | wc -l
如下图:
文章图片
文章图片
2、排查思路 1、我们先看一下TCP状态转换图:
文章图片
在图中可以看到:
CLOSE_WAIT: 这种状态的含义其实是表示在等待关闭。
当对方close一个SOCKET后发送FIN报文给自己,你会回应一个ACK报文给对方,此时则进入到CLOSE_WAIT状态。接下来,实际上你真正需要考虑的事情是察看你是否还有数据发送给对方,如果没有的话,那么你也就可以close这个SOCKET,发送FIN报文给对方,也即关闭连接。所以你在CLOSE_WAIT状态下,需要完成的事情是等待你去关闭连接。
2、知道了这种状态,那我们分析一下哪些情况会产生这种状态呢: 1、系统负载高
我第一个想到的就是系统的负载高,导致服务端相应比较慢,客户端等不急刷新,导致的CLOSE_WAIT。接下来就是排查。
查看监控并没有冲高的,CPU和内存都正常,带宽流入流出也正常,证明和系统无关系。(因为我们还跑了其他服务,运行和访问均正常)
2、程序没有设置超时断开
第二个就想到的是,程序里面没有设置超时自动断开。但是程序已经运行了一个多月,应该没有这方面的问题。
3、查看程序日志分析
没有思绪后去看了看程序的日志,发现机器在CLOSE_WAIT高的时候,程序一直报,连接数据库超时。如下图:
文章图片
查看数据库状态和负载均正常,而后和研发沟通,看是否使用连接池技术,研发说是使用了。按理说使用了连接池不至于一直连接不上啊,去看看连接池,查看连接池配置后发现了问题,
连接池配置的连接数为:maxActive=20,设置的连接数太小,客户量增加,已不满足要求。
3、解决办法 1、第一种情况:
对机器进行扩容,CPU和内存或磁盘和带宽。
2、第二种情况:
找研发查看代码是否存在这种问题,如果存在则修改代码。
3、第三种情况:
马上告诉研发,修改连接数后重新发布,查看日志以及CLOSE_WAIT均未出现问题。
4、临时清理CLOSE_WAIT 1、找出CLOSE_WAIT
netstat -anput | grep 8090 | grep CLOSE_WAIT | wc -l
文章图片
如图中的21725即为程序的id
2、Kill掉程序ID
kill -9 21725
【云原生|云上机器CLOSE_WAIT过多的原因和解决办法】再次查看即正常。
推荐阅读
- 云原生|云原生之容器化(Docker命令详解)
- 网络工程|QoS服务质量三DiffServ模型报文的标记及PHB
- 梅科尔工作室-华为14天鸿蒙设备开发实战笔记六
- 网络|我,AI博士生,在线众筹研究主题
- java|软件架构设计的核心(抽象与模型、“战略编程”)
- 编程语言|编程语言(类型系统的本质)
- Java项目|学习【瑞吉外卖⑥】SpringBoot单体项目_手机验证码登录业务开发
- springboot|springboot中实现短信验证(从零开始、腾讯云)
- 网络|万字长文详解Istio