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 conn_waiting
29: going from conn_waiting to conn_read
28: going from conn_new_cmd to conn_waiting
28: going from conn_waiting to conn_read
28: going from conn_read to conn_closing

从日志中可以看出,memcached没有接受命令就关闭连接了。

再从/var/log/messages日志中发现如下信息刷屏:

kernel: nf_conntrack: table full, dropping packet

这是iptables的报错信息“连接跟踪表已满,开始丢包”,再想到网站那面将memcached的连接改为短连接,由于iptables会记录每个连接的跟踪信息,而连接关闭关闭过于频繁导致连接跟踪表满,出现丢包。

解决方法:

首先将memcached的连接方法改为长链接,然后再针对nf_conntrack进行修改,主要有以下几种方式:

1.关闭防火墙

chkconfig iptables off
chkconfig ip6tables off
service iptables stop
service ip6tables stop

注意:在防火墙关闭的状态下,不要使用iptables -L -vnx来查看状态!因为这样会导致防火墙被启动,而且规则为空。虽然不会有任何拦截效果,但所有连接状态都会被记录,浪费资源且影响性能并可能导致防火墙主动丢包!

2.加大iptables跟踪表大小,调整对应的系统参数

3.使用裸表,不添加跟踪标志

4.删除连接跟踪模块

具体的修改过程请参考  ,这里说的比较详细。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/a21d3618d7d3d022bb8c7dac0e2232ff.html