服务器出现大量close_wait,我们来说说到底是怎么回事?(以tomcat为例)

时间:2024-01-24 17:22:18

一、问题描述

最近一直忙得很,好久没写博客。前两天,微信收到个好友申请,说是想问问close_wait的事情。

 

找他问了些详细信息,大概了解到,他们后端服务是tomcat 7, jdk 7,centos,传统的spring + hibernate + spring mvc 结构。

业务不清楚,客户端主要是微信小程序。

目前的症状就是,服务器上有大量的close_wait状态的连接,在他们的服务器上执行 netstat 命令,如下图:

 

从上图看出,他们的服务器ip为 172.18.206.252(反正是内网ip,不用打码了吧),端口是443,那应该就是https服务了。

客户端ip没有重样的,应该都是些全国各地的ip了。

close_wait的危害在于,在一个进程上打开的文件描述符超过一定数量,(在linux上默认是1024,可修改),新来的socket连接就无法建立了,因为每个socket连接也算是一个文件描述符。

会报:Too many open files。

这里详细说一下,linux上,每个进程,都有其自身的资源限制,比如最大可以打开的文件描述符数量。

比如下面,我查看了某个java进程的资源限制。

 

 这部分,可以查看以下链接:

https://feichashao.com/ulimit_demo/

 

二、问题分析

我回想了一下,之前在博客园上是写了一篇close_wait相关的,叫:tcp连接出现close_wait状态?可能是代码不够健壮

在那篇文章里,虽然我那也是服务端出现的,但是服务端其实是作为客户端,去调用大数据服务。严格来说,和今天遇到的场景不一样:

1、之前博客里的场景:服务端调用大数据,大数据关闭连接,(发起fin,服务器回ack)。此时,因为代码不严谨,服务端没有再向大数据发起close请求,

所以服务端与大数据的连接,在服务端上表现为close_wait。在大数据那边,状态应该是属于FIN_WAIT_2。参考下图:

 

 2、这次遇到的场景:是作为小程序的客户端访问了服务器,服务器不知道为啥处于close_wait。

所以,一开始我也没有思路,网上查了下,有人说是tomcat 的https有bug,更多的直接教你怎么用运维手段解决。

 

后来,这个朋友提到,他们服务器的一个接口,是会去调用微信服务器,生成二维码,而且,他们的监控显示,该方法耗时较长。

这时,我想到一个问题是:如果服务端在处理过程中,耗时较长,(进入死循环、等锁、下游服务响应慢等),假设20s才返回,

但是客户端明显不可能等那么久,一般5-10s就超时了。超时了,客户端发起fin,服务器回ack,此时,

服务器端应该就是close_wait。

 

在网上搜索时,也发现网上其实有这方面案例了,比如:

一次服务端大量CLOSE_WAIT问题的解决

 

我大概率估计,就是这个原因。但猜测只是猜测,还是要实践一下。

 

三、验证猜测

1、准备工作

我这边的一台开发服务器是windows的,装了wireshark,方便抓包,上面装了tomcat 8.5,一会直接把war包丢进去跑就完了。

我的打算是,修改目前工程的一个controller接口,让其睡眠30s再返回。 客户端的话,我用了httpclient,写了个测试类,直接去调用服务器的controller接口。

然后,用netstat观察该连接的状态变化,同时,wireshark辅助查看网络包的发送情况。

 

controller代码如下:

 

客户端代码:

pom.xml加上:

            <dependency>
                <groupId>org.apache.httpcomponents</groupId>
                <artifactId>httpclient</artifactId>
                <version>4.5.3</version>
            </dependency>

 

工具类如下:

import com.alibaba.fastjson.JSON;
import com.ceiec.base.common.utilities.AppConstants;
import org.apache.commons.io.IOUtils;
import org.apache.commons.lang3.time.StopWatch;
import org.apache.http.HttpEntity;
import org.apache.http.client.ClientProtocolException;
import org.apache.http.client.config.RequestConfig;
import org.apache.http.client.methods.CloseableHttpResponse;
import org.apache.http.client.methods.HttpPost;
import org.apache.http.entity.StringEntity;
import org.apache.http.impl.client.CloseableHttpClient;
import org.apache.http.impl.client.HttpClients;
import org.apache.http.message.BasicHeader;
import org.apache.http.protocol.HTTP;
import org.apache.http.util.EntityUtils;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import java.io.IOException;
import java.util.HashMap;

public final class MyHttpUtils {



    private static int TIMEOUT = 5000;

    private static final String APPLICATION_JSON = "application/json";

    private static final String CONTENT_TYPE_TEXT_JSON = "text/json";

    private static Logger logger = LoggerFactory.getLogger(MyHttpUtils.class);

    /**
     * POST方式提交请求
     * 
     * @param url 请求地址
     * @param json JSON格式请求内容
     * @throws IOException 
     */
    public static String doPost(String url, String json){
        if (json == null) {
            HashMap<String, String> map = new HashMap<>();
            json = JSON.toJSONString(map);
        }
        //计时
        StopWatch timer = new StopWatch();
        timer.start();

        RequestConfig defaultRequestConfig = RequestConfig.custom().setSocketTimeout(TIMEOUT).setConnectTimeout(TIMEOUT).setConnectionRequestTimeout(TIMEOUT).build();
        CloseableHttpClient httpClient = HttpClients.custom().setDefaultRequestConfig(defaultRequestConfig).build();
        HttpPost httpPost = new HttpPost(url);
        httpPost.addHeader(HTTP.CONTENT_TYPE, APPLICATION_JSON);
        StringEntity stringEntity = new StringEntity(json, AppConstants.UTF8);
        stringEntity.setContentType(CONTENT_TYPE_TEXT_JSON);
        stringEntity.setContentEncoding(new BasicHeader(HTTP.CONTENT_TYPE, APPLICATION_JSON));
        httpPost.setEntity(stringEntity);
        httpPost.setConfig(defaultRequestConfig);

        CloseableHttpResponse response = null;
        String responseContent = "";
        try {
            response = httpClient.execute(httpPost);
            int status = response.getStatusLine().getStatusCode();
            logger.debug("response status: " + status);
            if (status >= 200 && status < 300) {
                HttpEntity entity = response.getEntity();
                if (entity == null) {
                    return null;
                }
                responseContent = EntityUtils.toString(entity,"UTF-8");
                return responseContent;
            } else {
                throw new ClientProtocolException("Unexpected response status: " + status);
            }
        } catch (Exception e) {
            logger.error("error occured.{}",e);
            throw new RuntimeException(e);
        } finally {
            timer.stop();
            logger.info("doPost. requestUrl:{}, param:{},response:{},took {} ms", url,json,responseContent,timer.getTime());

            IOUtils.closeQuietly(response);
            IOUtils.closeQuietly(httpClient);
        }
    }


}

 

Test类:

public class Test {
    public static void main(String[] args) {
            MyHttpUtils.doPost("http://192.168.19.94:8080/CAD_WebService/getValue.do",null);
    }
}

 

好了,在正式开始之前,说下MyHttpUtils中标红的那个方法:RequestConfig.custom().setSocketTimeout(TIMEOUT) 这个setSocketTimeout表示设置等待服务器端响应超时的时间,这里设为5000,意为5s

 

 

2.测试验证

这里,准备就绪了,马上开始,我们启动了服务端,然后客户端发起调用,下面是我这边的抓包(服务端视角):

 

这个图,咱们先看抓包:

这个包,是在服务器192.168.19.94上抓的。抓的是服务器上8080端口,和我本地pc 10.15.4.46之间的网络包。

我们分析下:

序号为1/2/3的包: 三次握手,建立连接;

序号4的包:发起http请求,请求的controller方法,会睡眠30s

序号5的包:对序号4的包的ack。注意,此时时间为14:02:11

序号6的包:此时时间已经过去5s,客户端等不及了,(就你猴急?),于是不耐烦了,老子不等了,发了个fin过来,要分手。

序号7的包:服务器说:要分手?知道了。

 

此时服务器在干嘛,不好意思,要睡30s,这时才睡了5s,还没醒。

 

说完了包,我们再看看那个cmd,里面展示的是8080端口上的连接,可以看出来,此时该连接正处于close_wait状态。

 

。。。

25s后。。。

25s后,服务器终于醒了,睡得不错,给客户端发响应吧(序号8),但是呢,9号包可以看出来,我的开发机给服务器回了rst。

意思就是:我不认识你。(因为前面我的开发机就提了分手。。。)

 

3.gif图完整回放

由于是一边写一边截图的,所以有些图等写完了再想看的时候,已经没有了。

 

下面截个完整的,这里,把客户端超时改为20s,方便查看:

1、服务端视角,可以看到,超时前,为established,超时后,为close_wait。

 

2.客户端视角

 

 

四、说到底,问题怎么解决

扯了那么多,服务器出现大量close_wait,到底怎么解决? 指标不治本的方法我就不说了,直接网上搜下,改改linux参数即可。

这篇博客主要是治本,讲了close_wait出现的一种情况:

服务端接口耗时较长,客户端主动断开了连接,此时,服务端就会出现 close_wait。

 

那怎么解决呢?看看代码为啥耗时长吧。

另外,如果代码不规范的话,说不定在收到对方发起的fin后,自己根本就不会给人家发fin。(比如netty自己开发的框架那种)

没啥好说的,检查自己的代码吧,反正close_wait基本就是自己这边的问题了。

如果觉得有点帮助,麻烦点个推荐哈。

 

ps:我这里用chrome测过,用fiddler的composer也搞过,发现有些客户端会一直等响应,过了很久才会主动去发fin,所以用了httpclient测试。

pps:tomcat在什么情况会主动发起fin?其实我也想讲讲,因为和http的connection:keep-alive这些,都有点关系,放这篇文章的话,主题就有点不集中,放下篇吧。

 

网络上,我也发现有些差不多场景的文章:

https://blog.csdn.net/auo67284/article/details/101102578