云上机器CLOSE

• 1、问题描述
• • 1、情景再现
• 2、排查思路
• • 1、我们先看一下TCP状态转换图：
  • 2、知道了这种状态，那我们分析一下哪些情况会产生这种状态呢：
  • • 1、系统负载高
    • 2、程序没有设置超时断开
    • 3、查看程序日志分析
  • 3、解决办法
  • • 1、第一种情况：
    • 2、第二种情况：
    • 3、第三种情况：
  • 4、临时清理CLOSE_WAIT
  • • 1、找出CLOSE_WAIT
    • 2、Kill掉程序ID

       在阿里云上面的Centos机器上面跑的java程序，突然有人反馈访问特别慢，在接到反馈后，查看机器cpu和内存，所有指标都正常，查看服务占用的8090端口时发现有大量的CLOSE_WAIT。

netstat -anput | grep 8090
netstat -anput | grep 8090 | grep CLOSE_WAIT | wc -l

如下图：

在图中可以看到：
CLOSE_WAIT: 这种状态的含义其实是表示在等待关闭。
       当对方close一个SOCKET后发送FIN报文给自己，你会回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。接下来，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以close这个SOCKET，发送FIN报文给对方，也即关闭连接。所以你在CLOSE_WAIT状态下，需要完成的事情是等待你去关闭连接。

       我第一个想到的就是系统的负载高，导致服务端相应比较慢，客户端等不急刷新，导致的CLOSE_WAIT。接下来就是排查。
       查看监控并没有冲高的，CPU和内存都正常，带宽流入流出也正常，证明和系统无关系。（因为我们还跑了其他服务，运行和访问均正常）

       第二个就想到的是，程序里面没有设置超时自动断开。但是程序已经运行了一个多月，应该没有这方面的问题。

       没有思绪后去看了看程序的日志，发现机器在CLOSE_WAIT高的时候，程序一直报，连接数据库超时。如下图：
       查看数据库状态和负载均正常，而后和研发沟通，看是否使用连接池技术，研发说是使用了。按理说使用了连接池不至于一直连接不上啊，去看看连接池，查看连接池配置后发现了问题，
连接池配置的连接数为：maxActive=20，设置的连接数太小，客户量增加，已不满足要求。

       对机器进行扩容，CPU和内存或磁盘和带宽。

       找研发查看代码是否存在这种问题，如果存在则修改代码。

       马上告诉研发，修改连接数后重新发布，查看日志以及CLOSE_WAIT均未出现问题。

netstat -anput | grep 8090 | grep CLOSE_WAIT | wc -l

如图中的21725即为程序的id

kill -9 21725

再次查看即正常。