监控服务器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

此参数作用:

这个参数是系统同时保持timewait套接字的最大数量。如果超过这个数字,time-wait套接字将立刻被清除并打印警告信息。增大的话将会消耗更多的内存。

可能原因:

服务器的TCP连接数,超出了内核定义最大数。

解决方式:

写入/etc/sysctl.conf使之永久生效

net.ipv4.tcp_max_tw_buckets = 20000

sysctp -p


查看是否再次报错:

tail -f /var/log/messages (已解决)



时间: 2024-12-28 15:00:09

监控服务器time wait bucket table overflow内核小问题!的相关文章

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的问题

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,彻底弄清解决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

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

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

转 neighbour table overflow 问题解决

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