Skip to content

Latest commit

 

History

History
92 lines (66 loc) · 2.71 KB

time_wait_bucket_table_overflow.md

File metadata and controls

92 lines (66 loc) · 2.71 KB
Raw

系统kern日志不断重复输出：

...
... kernel: : __ratelimit: 133 callbacks suppressed
... kernel: : TCP: time wait bucket table overflow
... kernel: : TCP: time wait bucket table overflow
...
... kernel: : __ratelimit: 107 callbacks suppressed
... kernel: : TCP: time wait bucket table overflow
...

系统日志中如果有大量的kernel: : TCP: time wait bucket table overflow，则表明系统连接中有很多TIME_WAIT状态，一种可能是受到了DDOS攻击（如果连接是从大量IP访问，并且出现大量的SYN状态）。

__ratelimit: 133 callbacks suppressed 日志原因参考 __ratelimit解释

参考 kernel: TCP: time wait bucket table overflow 解决方法 来看看系统有多少连接

netstat -an | awk '{print $6}' | sort | uniq -c | sort -rn

显示输出

   7450 TIME_WAIT
     56 ESTABLISHED
     56 CONNECTED
	 13 LISTEN
	  9 STREAM
	  7 FIN_WAIT
	  4
	  1 I-Node
	  1 Foreign
	  1 FIN_WAIT2
      1 FIN_WAIT1
     81 LAST_ACK
...

检查tcp_max_tw_buckets

cat /proc/sys/net/ipv4/tcp_max_tw_buckets

输出显示

10000

原来设置值还是相对较大的。我检查了用户的/etc/sysctl.conf看到如下设置

#net.ipv4.tcp_max_tw_buckets=5000
net.ipv4.tcp_max_tw_buckets=10000

并且/etc/sysctl.conf修改时间戳是Mar 9 18:23，检查/var/log/kern日志中这个报错日志最后出现时间就是这个时间戳之后

Mar  9 18:23:35 kernel: : TCP: time wait bucket table overflow

说明用户已经发现了这个问题，并通过扩大TIME_WAIT bucket table解决了这个问题。

不过，为何会导致出现大量的TIME_WAIT呢？

参考 Too many TIME_WAIT connections inside container: time wait bucket table overflow

TCP: time wait bucket table overflow日志表明TCP sockets的TIME_WAIT状态，即TW buckets已经达到了内核中分配的内存上限。

可以通过以下命令检查TIME_WAIT数量

netstat -antp | grep TIME_WAIT | wc -l

可以通过以下命令检查 max_tw_buckets 设置

sysctl -a | grep tcp_max_tw_buckets

这个内核参数 tcp_max_tw_buckets 在 proc 中是 /proc/sys/net/ipv4/tcp_max_tw_buckets ，是一个全局设置。对于OpenVZ这样的容器虚拟化，还有一个针对每个容器设置的/proc/sys/net/ipv4/tcp_max_tw_buckets_ub是针对每个容器的。

参考