我在我们的集群中有一个节点，它在系统日志中获得大量的“nf_conntrack：table full，drop packet”消息。 我检查了nf_conntrack_count，它正好对着nf_conntrack_max运行。 纵观表格，我看到大部分条目都是DNS请求，所以我将这些规则添加到“raw”netfilter表中。
$ sudo iptables -t raw -vnL Chain PREROUTING (policy ACCEPT 146M packets, 19G bytes) pkts bytes target prot opt in out source destination 33M 4144M CT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:53 CT notrack 33M 2805M CT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 CT notrack Chain OUTPUT (policy ACCEPT 73M packets, 8311M bytes) pkts bytes target prot opt in out source destination 10785 882K CT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 CT notrack 0 0 CT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:53 CT notrack 这使计数盘旋在13000左右，而nf_conntrack_max设置为65535.但我仍然不断收到丢弃的数据包消息。 其余的大部分数据包都是UDP，我把nf_conntrack_udp_timeout设置为1秒，而把nf_conntrack_count留在1000左右。但是我仍然得到了丢弃的打包消息。
从这里，如果我提高最大值，它将停止丢弃的数据包消息，但我不明白为什么这是必要的。
我正在运行docker，并且有一个elasticsearch容器（这个问题似乎发生在任何运行elasticsearch的节点上）。 不确定它是否相关，但节点有48个核心。
$ uname -a Linux qtausc-pphd0128 3.19.0-26-generic #28~14.04.1-Ubuntu SMP Wed Aug 12 14:09:17 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
那么为什么在计数远低于最大值时丢包呢？
我在一个Squid系统上遇到了同样的问题。
我发现减lessconntrack的最有效的方法之一是减less内核中的默认TCP超时。
net.netfilter.nf_conntrack_tcp_timeout_established默认设置为net.netfilter.nf_conntrack_tcp_timeout_established 。 没错，那是5天
要设置该值，您可以发出以下命令;
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=X
如果你想要改变是持久的，你需要添加行到/etc/sysctl.conf 。
在将这个值降低到600之后，连续数字在几天内稳步下降。
我不知道你是如何检查conntrack表的计数和最大设置，但我使用了sysctl netfilter.nf_conntrack_max和sysctl net.netfilter.nf_conntrack_count为了得到值。