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 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.删除连接跟踪模块

具体的修改过程请参考http://my.oschina.net/kisops/blog/150995，这里说的比较详细。