记一次TCP TIME_WAIT引发的血案

2022-02-28 本文已影响0人 639c12a85b17

前言

记录线上一次故障，状态延迟，状态使用短连接，长轮训的方式获取，在每天的固定时间点，出现状态延迟，持续几分钟，然后又莫名其妙的恢复了，很是怪异，下面就来复盘下，这次问题的定位和思考。

冰山一角

我们可以掌握的线索有 1.固定的时间点，发生。2.通过监控可以看到，流量并不高，但是TCP TIMEWAIT一瞬间疯涨 3.出问题的时间点，远程客户的电脑（全内网），ping网关和服务器，发现有大量延时 4.有同事通过jstat看，发现gc的次数很多，认为gc导致了接口延时。5.接口超时的时间点，CPU不高，内存不高，I/O不高，系统负载不高，也就是未达到机器的性能瓶颈。机器配置16核64g

软件版本：

•操作系统 centos7.9•JDK 1.6•nginx7.7

由于，这个问题牵涉的大客户，很多技术人员，投入进来一起攻破，每个人的想法不一致，导致问题更难以统一突破。

一部分人，认为是网络问题，和某为扯了半天，没有个所以然一部分人，认为gc太频繁，full gc次数太多了，所以需要gc调优一部分人，认为需要在测试环境，压测，测试出系统瓶颈

实施的方案

抛开以上的言论，我们回到线索上

1、每天固定时间出现，询问客户，这个时间段是否是业务高峰期。回答：是

2、从监控来看，TCP-TIMEWAIT高，那我们就要先定位到系统部署方案。

系统部署方案如下 1.nginx反向代理java服务。nginx监听443端口 java服务监听8080端口

每一次轮训，发起http请求，通过nginx，nginx请求java服务

查看8080端口的tcp端口timewait个数，发现全是timewait，现在可以确定的是nginx和tcp连接出现了大量的timewait，导致接口延时。

翻了运维的调优记录如下:

•根据监控看，丢弃的连接数比较多

TCP 建立连接时要经过 3 次握手，在客户端向服务器发起连接时，对于服务器而言，一个完整的连接建立过程，服务器会经历 2 种 TCP 状态：SYN_REVD, ESTABELLISHED

对应也会维护两个队列：

一个存放 SYN 的队列（半连接队列）一个存放已经完成连接的队列（全连接队列）

•ESTABLISHED列长度如何计算？

如果 backlog 大于内核参数 net.core.somaxconn，则以 net.core.somaxconn 为准，

即全连接队列长度 = min(backlog, 内核参数 net.core.somaxconn)，net.core.somaxconn 默认为 128。

这个很好理解，net.core.somaxconn 定义了系统级别的全连接队列最大长度，

backlog 只是应用层传入的参数，不可能超过内核参数，所以 backlog 必须小于等于 net.core.somaxconn。

•SYN_RECV队列长度如何计算？

半连接队列长度由内核参数 tcp_max_syn_backlog 决定，

当使用 SYN Cookie 时（就是内核参数 net.ipv4.tcp_syncookies = 1），这个参数无效，

半连接队列的最大长度为 backlog、内核参数 net.core.somaxconn、内核参数 tcp_max_syn_backlog 的最小值。

即半连接队列长度 = min(backlog, 内核参数 net.core.somaxconn，内核参数 tcp_max_syn_backlog)。

这个公式实际上规定半连接队列长度不能超过全连接队列长度，但是tcp_syncooking默认是启用的，如果按上文的理解，那这个参数设置没有多大意义

其实，对于 Nginx/Tomcat 等这种 Web 服务器，都提供了 backlog 参数设置入口，当然它们都会有默认值，通常这个默认值都不会太大（包括内核默认的半连接队列和全连接队列长度）。如果应用并发访问非常高，只增大应用层 backlog 是没有意义的，因为可能内核参数关于连接队列设置的都很小，一定要综合应用层 backlog 和内核参数一起看，通过公式很容易调整出正确的设置

•nginx调优 nginx到java建立的连接Timewait比较大，优化nginx配置，降低握手次数。

    upstream node {
        server 127.0.0.1:8080;
        keepalive 10000; //新增
        keepalive_timeout 65s; //新增 
        keepalive_requests 20000; //新增
        }

•从以上记录看，似乎都和TCP连接数有关。解决思路如下：

1.长轮训短连接改为websocket方案评估：不确定因素太多，客户要限时解决问题，不敢上线 2.降低tcp 连接数，根据业务拆分，降低请求量。3.控制timewait数量，保证业务高峰期不会发生太大的抖动 4.询问业务人员，请求会分配到一个线程的处理，并且没有限制线程数量，所以如果请求量很大，应该会有很多线程，并且cpu应该有很高的使用量，而现在cpu的使用量很低，不太正常。使用jstack打印线程情况

实施

•

找到运维沟通，tcp的连接数设置高点。然而被告知最多只能创建65535个。这个问题我们稍后在细聊下。

•

控制TCP TIMEWAIT的数量，设置参数

net.ipv4.tcp_max_tw_buckets=1024

•

jstack打印线程池，发现有很多线程在等待同一个锁。锁是使用synchronized关键字，锁的是HashTable一个数组，锁的代码逻辑，处理比较长。优化：拆分锁的逻辑，不需要一致性的数据踢出去。

后记

一台机器最多能创建多少个TCP连接？

上面的截图中，tcp timewait的个数太多，到了65535限制，导致连接被重置，那为什么有这个结论呢注意看上面的nginx配置

    upstream node {
        server 127.0.0.1:8080;
        keepalive 10000; //新增
        keepalive_timeout 65s; //新增 
        keepalive_requests 20000; //新增
        }

这里指定了去连接127.0.0.1的8080端口，那么nginx去连接java服务的时候如下：| 源ip| 源端口 |目标ip |目标端口 | |--|--|--|--| | 127.0.0.1|20000 |127.0.0.1 |8080 | | 127.0.0.1|20001 |127.0.0.1 |8080 | | 127.0.0.1|20002 |127.0.0.1 |8080 |

所以为什么会说一个机器上最多65535个端口数。这个端口号16位的，可以有0~65535端口数是针对单个ip来描述的，那我们在机器上可不是只有一个ip，所以理论上端口数是无上限的，配置nginx的时候这里需要注意上。

•端口号的上限不一定是65535 如果你有幸见过cannot assign requested address 那么你一定知道 Linux对可使用的范围端口有具体限制，使用以下命令查看

cat /proc/sys/net/ipv4/ip_local_port_range 
1024 65000

•文件描述符 Linux 下一切皆文件我们突破tcp端口限制的时候，很可能会遇到以下错误too many open files

每建立一个TCP连接，会分配一个文件描述符，linux 对可打开的文件描述符的数量分别作了三个方面的限制。

系统级：当前系统可打开的最大数量，通过 cat /proc/sys/fs/file-max 查看

用户级：指定用户可打开的最大数量，通过 cat /etc/security/limits.conf 查看

进程级：单个进程可打开的最大数量，通过 cat /proc/sys/fs/nr_open 查看

•C10K 每创建一个TCP连接，操作系统都需要消耗一个线程，当我们TCP连接数过多，会导致线程不停的上下文切换，导致cpu处理时间越来越长。C10K就是早期单机性能的瓶颈代名词。所以后续有了 I/O多路复用模型。

何时进行JVM调优？

还记得上面说过，通过jstat看到gc很频繁，full gc次数很多，所以建议GC调优吗？我们看关键指标

YGC 59085 Young GC次数 
YGCT 318.142 Young 总时间 单位秒
FGC 407 Full GC 次数
FGCT 75.310 Full GC 总时间，单位为妙
我们看平均时间

年轻代平均gc时间
318.142/59085=0.0005
- 老年代平均gc时间
75.310/407=0.185

我们可以看到GC的次数很多，但是GC的平均时间并不高。

但是这并不是万能的

有一种情况比如Full GC发生了10次，平均值不高，但是某几次的Full GC时间为5~6秒，所以为了更确定这个问题，我们可以使用启动参数，查看每次GC的时间。

-verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:./gc.log

查看当天gc日志，Full gc时间并不高，可以排除，GC引起的问题。

所有的优化，GC调优应该是最后的手段，更多的是优化我们的代码。

本文使用文章同步助手同步