一次TCP TIME_WAIT连接数过多告警处理1、前言2、问题回顾3、解决方案更多技术文章快来关注“运维之美”不定期更新领取IT学习资料1、前言客户环境上在业务高峰期的时候突然收到主机的TCP time_wait连接数告警过多的告警。运维侧及时介入分析通过本文的处理方式和思路希望给你在问题处理过程中提供灵感。2、问题回顾客户反馈收到如下告警主机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 异常TipsTCP 本地端口数量上限为 655356.5w这是因为 TCP 头部使用 16 bit存储「端口号」因此约束上限为 65535。time_wait 状态的影响TCP 连接中「主动发起关闭连接」的一端会进入 time_wait 状态time_wait 状态默认会持续 2 MSL报文的最大生存时间time_wait 状态下TCP 连接占用的端口无法被再次使用TCP 端口数量上限是 6.5w6553516 bitnet.ipv4.ip_local_port_range102465000#端口数和这个参数有关系大量 time_wait 状态存在会导致新建 TCP 连接会出错address already in use : connect 异常大量的连接会导致服务器资源使用上升现实场景服务内部调用过多优化业务模式也可以是连接关闭方式需要优化Nginx 反向代理场景中可能出现大量短链接服务器端可能存在解决思路1、服务器端允许 time_wait 状态的 socket 被重用2、缩减 time_wait 时间设置为 1 MSL即2 mins3、解决方案TCP连接数统计脚本#!/bin/shforiin/proc/*;doif[-d$i/fd];thenecho$i$(ls$i/fd-l|grepsocket:|wc-l)fidone通过这个脚本可以统计出当前分配连接数的进程通过进程可以找到对应的服务如果是服务关闭连接的姿势不对业务方优化即可在业务侧解决此问题之前我们可以通过操作系统的内核参数缓解此问题方案修改配置文件/etc/sysctl.conf1、允许将TIME_WAIT状态的socket重新用于新的TCP连接net.ipv4.tcp_tw_reuse1#默认为0表示关闭如果为0修改为12、快速回收TIME_WAIT状态的socketnet.ipv4.tcp_tw_recycle1#修改为1默认为03、修改time_wait连接数的回收时间cat/proc/sys/net/ipv4/tcp_fin_timeout#查看默认的MSL值net.ipv4.tcp_fin_timeout30#如果为60修改为30s回收最后sudo sysctl -p 使配置生效即可从修改前后的效果上可以看到timewait的回收明显加快了 一次TCP TIME_WAIT连接数过多告警处理
一次TCP TIME_WAIT连接数过多告警处理1、前言2、问题回顾3、解决方案更多技术文章快来关注“运维之美”不定期更新领取IT学习资料1、前言客户环境上在业务高峰期的时候突然收到主机的TCP time_wait连接数告警过多的告警。运维侧及时介入分析通过本文的处理方式和思路希望给你在问题处理过程中提供灵感。2、问题回顾客户反馈收到如下告警主机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 异常TipsTCP 本地端口数量上限为 655356.5w这是因为 TCP 头部使用 16 bit存储「端口号」因此约束上限为 65535。time_wait 状态的影响TCP 连接中「主动发起关闭连接」的一端会进入 time_wait 状态time_wait 状态默认会持续 2 MSL报文的最大生存时间time_wait 状态下TCP 连接占用的端口无法被再次使用TCP 端口数量上限是 6.5w6553516 bitnet.ipv4.ip_local_port_range102465000#端口数和这个参数有关系大量 time_wait 状态存在会导致新建 TCP 连接会出错address already in use : connect 异常大量的连接会导致服务器资源使用上升现实场景服务内部调用过多优化业务模式也可以是连接关闭方式需要优化Nginx 反向代理场景中可能出现大量短链接服务器端可能存在解决思路1、服务器端允许 time_wait 状态的 socket 被重用2、缩减 time_wait 时间设置为 1 MSL即2 mins3、解决方案TCP连接数统计脚本#!/bin/shforiin/proc/*;doif[-d$i/fd];thenecho$i$(ls$i/fd-l|grepsocket:|wc-l)fidone通过这个脚本可以统计出当前分配连接数的进程通过进程可以找到对应的服务如果是服务关闭连接的姿势不对业务方优化即可在业务侧解决此问题之前我们可以通过操作系统的内核参数缓解此问题方案修改配置文件/etc/sysctl.conf1、允许将TIME_WAIT状态的socket重新用于新的TCP连接net.ipv4.tcp_tw_reuse1#默认为0表示关闭如果为0修改为12、快速回收TIME_WAIT状态的socketnet.ipv4.tcp_tw_recycle1#修改为1默认为03、修改time_wait连接数的回收时间cat/proc/sys/net/ipv4/tcp_fin_timeout#查看默认的MSL值net.ipv4.tcp_fin_timeout30#如果为60修改为30s回收最后sudo sysctl -p 使配置生效即可从修改前后的效果上可以看到timewait的回收明显加快了