TCP: time wait bucket table overflow问题解决

新上的服务器发生两次负载过高,而不能访问其网站的问题,因为是新上阿里云的ECS,第一次出现这个问题没太在意重启了下就好了(比起服务器在机房打电话重启方便多了),第二次放生的时候查看了下日志有大量的TCP: time wait bucket table overflow。

解决方法:

修改vim /etc/sysctl.conf
net.ipv4.tcp_max_tw_buckets = 50000
调大timewait 的数量
net.ipv4.tcp_fin_timeout = 10
如果套接字由本端要求关闭,这个参数决定了它保持在FIN-WAIT-2 状态的时间。对端可以出错并永远不关闭连接,甚至意外当机。缺省值是60 秒。2.2 内核的通常值是180 秒,3你可以按这个设置,但要记住的是,即使你的机器是一个轻载的WEB 服务器,也有因为大量的死套接字而内存溢出的风险,FIN- WAIT-2 的危险性比FIN-WAIT-1 要小,因为它最多只能吃掉1.5K 内存,但是它们的生存期长些。
net.ipv4.tcp_tw_recycle= 1
启用timewait 快速回收
net.ipv4.tcp_tw_reuse = 1
开启重用,允许将TIME-WAIT sockets 重新用于新的TCP 连接
保存设置
sysctl -p

解决过程:

这个问题第一次遇到,上网搜了下,整理了一下直接复制过来。

TIME_WAIT的产生条件:主动关闭方在发送四次挥手的最后一个ACK会变为TIME_WAIT状态,保留次状态的时间为两个MSL(linux里一个MSL为30s,是不可配置的)

TIME_WAIT两个MSL的作用:可靠安全的关闭TCP连接。比如网络拥塞,主动方最后一个ACK被动方没收到,这时被动方会对FIN开启TCP重传,发送多个FIN包,在这时尚未关闭的TIME_WAIT就会把这些尾巴问题处理掉,不至于对新连接及其它服务产生影响。

TIME_WAIT占用的资源:少量内存(查资料大概4K)和一个fd。

TIME_WAIT关闭的危害:

1、  网络情况不好时,如果主动方无TIME_WAIT等待,关闭前个连接后,主动方与被动方又建立起新的TCP连接,这时被动方重传或延时过来的FIN包过来后会直接影响新的TCP连接;

2、  同样网络情况不好并且无TIME_WAIT等待,关闭连接后无新连接,当接收到被动方重传或延迟的FIN包后,会给被动方回一个RST包,可能会影响被动方其它的服务连接。

TCP: time wait bucket table overflow产生原因及影响:原因是超过了linux系统tw数量的阀值。危害是超过阀值后﹐系统会把多余的time-wait socket 删除掉,并且显示警告信息,如果是NAT网络环境又存在大量访问,会产生各种连接不稳定断开的情况。

时间: 2024-10-12 22:11:34

TCP: time wait bucket table overflow问题解决的相关文章

linux TCP: time wait bucket table overflow

早上一台rabbitmq和Java所在的服务器,客户端反馈超级卡,看io和cpu都不高.发现六七万消息挤压,临时性问题解决之后,看/var/log/messages,发现很多TCP: time wait bucket table overflow,如下所示: Nov 22 10:36:08 iZ237hn51s7Z kernel: TCP: time wait bucket table overflowNov 22 10:36:08 iZ237hn51s7Z kernel: TCP: time

message日志报错:TCP: time wait bucket table overflow,K哥

2015.9.13 message日志报错:TCP: time wait bucket table overflow 网上很多解决办法,我也是百度的,哈哈 先盗一张图,因为问题已经很久了,没截图 K哥盗图. 这个报错需要更改net.ipv4.tcp_max_tw_buckets这个内核参数. 这个参数是系统同时保持timewait套接字的最大数量. 如果超过这个数字,time-wait套接字将立刻被清除并打印警告信息. 这个限制仅仅是为了防止简单的 DoS攻击. 解决方法: 增大 tcp_max

理解TIME_WAIT,彻底弄清解决TCP: time wait bucket table overflow

一直对这个问题知其然而不知其所以然,这些日子再次碰到,看了很多的资料,彻底解决一下,呵呵,先上个图,所有理解围绕着此图来看,此图描述了四次挥手的整个过程: 通过此图先说明几个概念: TIME_WAIT的产生条件:主动关闭方在发送四次挥手的最后一个ACK会变为TIME_WAIT状态,保留次状态的时间为两个MSL(linux里一个MSL为30s,是不可配置的) TIME_WAIT两个MSL的作用:可靠安全的关闭TCP连接.比如网络拥塞,主动方最后一个ACK被动方没收到,这时被动方会对FIN开启TCP

kernel: TCP: time wait bucket table overflow 的解决

今天机器的日志有下面的报错: Oct 22 15:22:19 web1 kernel: TCP: time wait bucket table overflow Oct 22 15:22:19 web1 kernel: TCP: time wait bucket table overflow Oct 22 15:22:19 web1 kernel: TCP: time wait bucket table overflow Oct 22 15:22:19 web1 kernel: TCP: tim

kernel: TCP: time wait bucket table overflow的问题

kernel: TCP: time wait bucket table overflow的问题 最近用elk收集系统日志,发现某些机器有很多内核报错 网上大多数的说法是要把net.ipv4.tcp_max_tw_buckets 这个内核参数调大.但是没说原理 我想了一下,其实tw_buckets的含义是time wait bucket table 这个表满了. 为什么会满? netstat -an|more 看time_out的链接 一般是80端口,也就是web server导致,那么就很自然的

kernel TCP time wait bucket table overflow

# 故障描述 有一个需求是实时分析API接口访问日志,提取token去数据库查询对应的uid,然后收集一些指标存入到hbase中. 当程序执行一会后会被系统杀死 Killed ! # 故障排查 1.CPU平均负载0.06.内存空闲29G 2.查看系统日志 /var/log/messages 提示:kernel: TCP: time wait bucket table overflow 3.查找资料发现是因为 socket TIME_WAIT 超出了内核设定的上限值 # 解决方法 shell >

转 neighbour table overflow 问题解决

接到保障,说某来机器服务没法访问,于是,准备连接到机器上去看个究竟. 尼玛居然连不上,连ping都ping不通,无奈只能求助机房. 机房人员检查, 发现报 neighbour table overflow 错误. 无奈让机房的人员重启了服务器. 查找原因,搜索得到如下说法: 第一种说法: 内核维护的arp表过于庞大, 发生抖动, 因此导致了这种情况,几个内核ARP参数:=================================gc_stale_time决定检查一次相邻层记录的有效性的周期

监控服务器time wait bucket table overflow内核小问题!

问题: 排查: [[email protected] ~]#netstat -auptn |awk '/^tcp/ {++state[$6]} END {for(key in state) printf("%-10s\t%d\n",key,state[key]) }' TIME_WAIT 15382 ESTABLISHED3 SYN_RECV  1 LISTEN    11 检查内核参数: net.ipv4.tcp_max_tw_buckets = 5000 此参数作用: 这个参数是系

hive中的bucket table

前言 bucket table(桶表)是对数据进行哈希取值,然后放到不同文件中存储 应用场景 当数据量比较大,我们需要更快的完成任务,多个map和reduce进程是唯一的选择.但是如果输入文件是一个的话,map任务只能启动一个.此时bucket table是个很好的选择,通过指定CLUSTERED的字段,将文件通过hash打散成多个小文件. create table test (id int, name string ) CLUSTERED BY(id) SORTED BY(name) INTO