kernel nf_conntrack: table full, dropping packet 解决办法

今天通过zabbix监控发现,有一台服务器出现网络不稳定,zabbix图像断流,随之,登录服务器经过排查,发现/var/log/messages中出现大量kernel nf_conntrack: table full, dropping packet 。

解决方法如下。

对ip_conntrack的两个参数进行设置即可,不过在centos上,需要这样设置: centos5


1

2

3

4

5


vi /etc/sysctl.conf

net.ipv4.netfilter.ip_conntrack_max = 655350

net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 1200

#默认超时时间为5天,作为一个主要提供HTTP服务的服务器来讲,完全可以设置得比较短

sysctl -p # 让刚刚修改过的设置生效

如果在执行sysctl -p 时提示错误 unknown key,那么表示内核版本比较高,参数名称已经改为 centos6


1

2


net.netfilter.nf_conntrack_max = 655350

net.netfilter.nf_conntrack_tcp_timeout_established = 1200

至于为什么会有这样的设置,这个设置的作用是什么,就要从NAT说起了。NAT(Network Address Translation,网络地址转换)是将IP数据报报头的IP地址转化成另外一个IP地址的过程,主要用来实现局域网内的机器访问公共网络(俗称外网)的功能。公共IP地址是指在因特网上全球唯一的IP地址,RFC 1918协议还为局域网预留出了三个IP不会在公网上进行分配的地址块:

  • 10.0.0.0~10.255.255.255
  • 172.16.0.0~172.31.255.255
  • 192.168.0.0~192.168.255.255

这些IP地址就可以用来分配给局域网上的各种设备,这些设备在访问外网时,就需要通过一台NAT服务器进行路由转换,通常情况下,路由器就兼备了这样一个功能。除了路由器,也可以配置linux服务器实现NAT功能。ip_conntrack就是linux NAT的一个跟踪连接条目的模块,ip_conntrack模块会使用一个哈希表记录 tcp 通讯协议的 established connection记录,当这个哈希表满了的时候,便会导致nf_conntrack: table full, dropping packet错误。

关于如何优化conntrack模块,有一篇文章对此进行了解释,Netfilter conntrack performance tweaking, v0.8,为了访问方便,我这里也留一个备份地址 netfilter_conntrack_perf-0.8.txt

查看目前 ip_conntrack 配置的值


1

2


> cat /proc/sys/net/ipv4/ip_conntrack_max

> cat /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established

查看目前 ip_conntrack buffer 的使用状况


1

2

3


> cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count

> grep ip_conntrack /proc/slabinfo

ip_conntrack       38358  64324    304   13    1 : tunables   54   27    8 : slabdata   4948   4948    216

其中各个数字的含义为:


1

2

3

4


38358 the number of currently active objects

64324 the total number of available objects

  304 the size of each object in bytes

   13 the number of pages with at least one active object

查出目前 ip_conntrack 记录最多的前十名 IP


1

2

3

4

5

6

7

8

9

10

11

12


> cat /proc/net/ip_conntrack | cut -d ‘ ‘ -f 10 | cut -d ‘=‘ -f 2 | sort | uniq -c | sort -nr | head -n 10

# 结果示例

#   6801 127.0.0.1

#   3993 122.224.190.62

#   1101 183.28.42.100

#   1004 222.73.254.95

#    549 120.42.98.143

#    483 114.135.81.206

#    460 123.154.46.196

#    431 222.242.121.122

#    410 125.33.21.174

#    312 222.211.218.59

时间: 2024-10-07 07:39:40

kernel nf_conntrack: table full, dropping packet 解决办法的相关文章

nf_conntrack: table full, dropping packet解决方法

在添加magent代理后,做memcached测试的发现,如果并发很高,数据库的连接数居高不下,按理讲随着将key存入缓存中,连接数应该慢慢降下来才对,但是当并发低的时候却很正常. 由于在启动memcached时,加入了-vvv参数打印内部状态信息,查看日志: 29: going from conn_parse_cmd to conn_write 29: going from conn_write to conn_new_cmd 29: going from conn_new_cmd to co

[转]nf_conntrack: table full, dropping packet 连接跟踪表已满,开始丢包 的解决办法

nf_conntrack: table full, dropping packet  连接跟踪表已满,开始丢包 的解决办法 中午业务说机器不能登录,我通过USM管理界面登录单板的时候发现机器没有僵死,然后一看日志,g一下子就明白了 tail -2000 /var/log/messages Apr 10 12:48:35 bj-push-pushserver83 kernel: [95129.138804] __ratelimit: 16523 callbacks suppressed (“连接跟

linux云主机cpu一直很高降不下来,系统日志报nf_conntrack: table full, dropping packet.

在启用了iptables web服务器上,流量高的时候经常会出现下面的错误: ip_conntrack: table full, dropping packet 这个问题的原因是由于web服务器收到了大量的连接,在启用了iptables的情况下,iptables会把所有的连接都做链接跟踪处理,这样iptables就会有一个链接跟踪表,当这个表满的时候,就会出现上面的错误. iptables的链接跟踪表最大容量为/proc/sys/net/ipv4/ip_conntrack_max,链接碰到各种状

nf_conntrack: table full, dropping packet 解决方案

"连接跟踪表已满,开始丢包"!相信不少用iptables的同学都会见过这个错误信息吧,这个问题曾经也困扰过我好长一段时间.此问题的解决办法有四种(nf_conntrack 在CentOS 5 / kernel <= 2.6.19中名为 ip_conntrack ): 一.关闭防火墙. 简单粗暴,直接有效 chkconfig iptables off  chkconfig ip6tables off  service iptables stop  service ip6tables

解决nf_conntrack: table full, dropping packet问题

echo "6553500" > /proc/sys/net/nf_conntrack_max iptables -t raw -A PREROUTING -p tcp -m tcp --dport 80 -j NOTRACK iptables -t raw -A OUTPUT -p tcp -m tcp --dport 80 -j NOTRACK 原理:http://jerrypeng.me/2014/12/08/dreadful-nf-conntrack-table-full

kernel: ip_conntrack: table full, dropping packet.

解决方法: 1. 更改ip_conntrack大小 # /etc/sysctl.conf Centos5.x: modprobe ip_conntrack sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=10800 sysctl -w net.ipv4.netfilter.ip_conntrack_max=655350 Centos6.x: nf_conntrack_ipv4 sysctl -w net.netf

table full, dropping packet.

系统日志/var/log/messages出现以下内容 Jan 31 16:46:41 ahmobileblivemedia02 kernel: nf_conntrack: table full, dropping packet. Jan 31 16:46:41 ahmobileblivemedia02 kernel: nf_conntrack: table full, dropping packet. Jan 31 16:46:41 ahmobileblivemedia02 kernel: n

&#39;weblogic.kernel.Default (self-tuning) 问题weblogic层面解决办法

声明:出现这个问题有程序方面.网络方面.weblogic设置方面等等原因,此文章主要讲述由于weblogic设置而导致的解决办法. 因为: 1.程序问题,需要项目自己去解决,weblogic在做优化处理也于事无补. 2.网络中断或者认为关闭交互这种情况也不能用weblogic处理(这点我是这么认为的) 一.说明: ,"weblogic.kernel.Default"是从客户端提交请求后产生的线程所在的队列名.这个队列的线程数默认是15个.如果超过15个线程堵塞,则部署的应用将不能访问.

mysql show table status报错解决办法

在数据库上执行show table status命令,报错如下图所示: 但是在数据库上是没有空用户的,下图验证: 那就可以判断不是数据库用户授权的问题,那就可能是数据库视图的问题,当打开该库的视图时,出现如下错误: 原因:此数据库视图是由[email protected]%用户建立的,然而该用户不存在于数据库中,当用其他用户执行时默认就被拒绝了 现在查看视图的定义者为[email protected]%: 解决办法:修改视图定义者为当前用户,执行如下sql语句: create or replac