最近我们的一台服务器（Debian Squeeze）在重负载时变得没有响应。 看看内核日志，我认为这是原因：
kernel: nf_conntrack: table full, dropping packet 据我所知，这是conntrack模块，它做了一些有状态的连接跟踪，报告用于存储连接细节的表已满。
从我所做的研究来看，似乎有两种方法可以缓解这个问题：
增加表格的大小。
完全从系统中取出模块。
但是，这台机器上不存在/proc/sys/net/ipv4/ip_conntrack_max和/proc/sys/net/ipv4/netfilter/ip_conntrack_max （ net下没有ipv4目录）。
如果我做lsmod我没有结果。
所以，我有点困惑 – 也许有人可以澄清我的情况？
谢谢
这是从经验 – 我还没有做研究，以validation这些信息：我已经看到了一些系统，其中相同的错误是在系统日志中，并没有/ proc / sys / net / ipv4 / ip_conn *或/ proc / SYS /网/的IPv4 / netfilter的。 我也想知道为什么 – 但是一旦你find了原有症状的解决办法，那么这个问题就不会很重要。 ;）
缓解策略是双重的：通过sysctl（天真的短期方法）增加限制，并找出为什么被跟踪的连接数目如此之高。
如果超出了默认限制，并且所涉及的服务器不打算处理大量的连接，那么根本不应该打到这个限制。 具有高连接跟踪要求的服务的一个很好的例子是服务于数十万客户的“公共”DNS服务器。
缓解措施是查看日志，确保防DOS / DDOS措施到位（例如，参见fail2ban），并确保安装了明智的防火墙configuration。
关于lsmod，我还没有遇到它似乎活跃的情况，但模块没有列出。 我不确定这种情况是怎么发生的。
conntrack的设置通常在/ proc / sys / net / netfilter / nf_conntrack_max中。