云上机器CLOSE_WAIT过多的原因和解决办法

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

再次查看即正常。

这篇好文章是转载于：学新通技术网