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 overflow
Nov 22 10:36:08 iZ237hn51s7Z kernel: TCP: time wait bucket table overflow
Nov 22 10:37:07 iZ237hn51s7Z kernel: __ratelimit: 47 callbacks suppressed
Nov 22 10:37:07 iZ237hn51s7Z kernel: TCP: time wait bucket table overflow
Nov 22 10:37:07 iZ237hn51s7Z kernel: TCP: time wait bucket table overflow
Nov 22 10:37:07 iZ237hn51s7Z kernel: TCP: time wait bucket table overflow
Nov 22 10:37:07 iZ237hn51s7Z kernel: TCP: time wait bucket table overflow
Nov 22 10:37:07 iZ237hn51s7Z kernel: TCP: time wait bucket table overflow
Nov 22 10:37:07 iZ237hn51s7Z kernel: TCP: time wait bucket table overflow
Nov 22 10:37:07 iZ237hn51s7Z kernel: TCP: time wait bucket table overflow

经查，发现net.ipv4.tcp_max_tw_buckets = 5000 ##已经修改

netstat -ano | grep wait | wc -l发现4400多，进一步查询，发现大量本机到mysql的连接状态处于该状态，进一步发现，有个应用的maxStatement被设置成了0。

时间： 2024-10-13 16:51:00

linux TCP: time wait bucket table overflow的相关文章

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

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

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 如果套接

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

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 >

监控服务器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 此参数作用: 这个参数是系

Linux tcp被动打开内核源码分析

[我是从2个角度来看,其实所谓2个角度,是发现我分析源码时,分析重复了,写了2个分析报告,所以现在都贴出来.] [如果你是想看看,了解一下内核tcp被动打开时如何实现的话,我觉得还是看看概念就可以了,因为即使看了源码,过一个个礼拜你就忘了,如果是你正在修改协议栈,为不知道流程而发愁,那么希望你能看看源码以及注释,希望你给你帮助.] 概念: tcp被动打开,前提是你listen,这个被动打开的前提.你listen过后,其实创建了一个监听套接字,专门负责监听,不会负责传输数据. 当第一个syn包到达

Linux TCP拥塞控制中undo操作

Linux的TCP实现复杂且繁琐,建议不要直接去看代码,而是花点时间把TCP规范先撸一遍.本文主要描述一下TCP实现中undo操作,然后顺便再吐一下槽(千万不要觉得吐槽有什么不好,很多好东西都是从吐槽开始的,从造纸,蒸汽机,到法兰西第一共和国,再到Linux...). 1.TCP对网络拥塞是基于预测的 TCP属于网络的一部分,这无可厚非,但当一个人说自己精通网络的时候,他更可能的意思是自己精通网络节点的行为而不是端到端的行为.比如,一个Cisco的工程师精通各种路由协议,可以设计出复杂的OSPF