问题回顾
客户反馈收到如下告警，主机TCP timewait连接数过多
prometheus告警表达式
node_sockstat_TCP_tw > 50000
收到连接数过多的告警并不代表一定会产生生产问题，此时要关注负载是否直线上升，连接数一直无法释放，如果出现此情况，则需要及时处理，避免造成生产环境宕机。
连接数数据来源：/proc/net/sockstat
线上场景中，持续的高并发场景
-
一部分 TIME_WAIT 连接被回收，但新的 TIME_WAIT 连接产生，新产生的连接数超过释放的速度；
- 一些极端情况下，会出现大量的 TIME_WAIT 连接。
Think：上述大量的 TIME_WAIT 状态 TCP 连接，有什么业务上的影响吗？
Nginx 作为反向代理时，大量的短链接，可能导致 Nginx 上的 TCP 连接处于 time_wait 状态：
每一个 time_wait 状态，都会占用一个「本地端口」，上限为 65535
当大量的连接处于 time_wait 时，新建立 TCP 连接会出错，address already in use : connect 异常
Tips：TCP 本地端口数量，上限为 65535（6.5w），这是因为 TCP 头部使用 16 bit，存储「端口号」，因此约束上限为 65535。
图片
- time_wait 状态的影响
TCP 连接中，「主动发起关闭连接」的一端，会进入 time_wait 状态
time_wait 状态，默认会持续 2 MSL（报文的最大生存时间）
time_wait 状态下，TCP 连接占用的端口，无法被再次使用
TCP 端口数量，上限是 6.5w（65535，16 bit）
net.ipv4.ip_local_port_range = 1024 65000 #端口数和这个参数有关系
大量 time_wait 状态存在，会导致新建 TCP 连接会出错，address already in use : connect 异常
大量的连接会导致服务器资源使用上升
- 现实场景
服务内部调用过多，优化业务模式，也可以是连接关闭方式需要优化
Nginx 反向代理场景中，可能出现大量短链接，服务器端可能存在
- 解决思路
1、服务器端允许 time_wait 状态的 socket 被重用
2、缩减 time_wait 时间，设置为 1 MSL（即，2 mins）
解决方案
TCP连接数统计脚本
#!/bin/sh
for i in /proc/* ;
do
if [ -d $i/fd ];then
echo $i $(ls $i/fd -l | grep socket: |wc -l)
fi
done
通过这个脚本可以统计出当前分配连接数的进程，通过进程可以找到对应的服务，如果是服务关闭连接的姿势不对，业务方优化即可
在业务侧解决此问题之前，我们可以通过操作系统的内核参数缓解此问题
方案
修改配置文件/etc/sysctl.conf
1、允许将TIME_WAIT状态的socket重新用于新的TCP连接
net.ipv4.tcp_tw_reuse = 1 #默认为0，表示关闭，如果为0，修改为1
2、快速回收TIME_WAIT状态的socket
net.ipv4.tcp_tw_recycle = 1 #修改为1，默认为0
3、修改time_wait连接数的回收时间
cat /proc/sys/net/ipv4/tcp_fin_timeout #查看默认的MSL值 net.ipv4.tcp_fin_timeout = 30 #如果为60，修改为30s回收
最后sudo sysctl -p 使配置生效即可，从修改前后的效果上可以看到，timewait的回收明显加快了
原文地址：https://mp.weixin.qq.com/s/sYYXGB3ICWN7FBmoJkPo1Q
