文章目录
- 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再次查看即正常。
