在对HTTP服务器性能不佳的抱怨进行调查时，我发现在我的Xen XCP主机的dmesg中包含这个服务器的客户操作系统的这些行：
[11458852.811070] net_ratelimit：321callback被抑制 [11458852.811075] nf_conntrack：表满，丢包。 [11458852.819957] nf_conntrack：表满，丢包。 [11458852.821083] nf_conntrack：表满，丢包。 [11458852.822195] nf_conntrack：表满，丢包。 [11458852.824987] nf_conntrack：表满，丢包。 [11458852.825298] nf_conntrack：表满，丢包。 [11458852.825891] nf_conntrack：表满，丢包。 [11458852.826225] nf_conntrack：表满，丢包。 [11458852.826234] nf_conntrack：表满，丢包。 [11458852.826814] nf_conntrack：表满，丢包。
抱怨每五秒重复一次（抑制callback次数每次都不相同）。
这些矛盾是什么意思？ 那不好吗？ 任何提示？
（请注意，这个问题比“如何解决HTTP服务器性能不佳的特定情况”更为狭窄，所以我没有提供更多细节。）
附加信息：
$ uname -a Linux MYHOST 3.2.0-24-generic＃37-Ubuntu SMP Wed Apr 25 08:43:22 UTC 2012 x86_64 x86_64 x86_64 GNU / Linux $ lsb_release -a 没有LSB模块可用。 经销商ID：Ubuntu 描述：Ubuntu 12.04 LTS 发布：12.04 代号：精确 $ cat / proc / sys / net / netfilter / nf_conntrack_max 1548576
该服务器在每天大约10M次点击/负载下。
更新：
在Dom0上的iptables：
$ iptables -L -t nat -v 链PREROUTING（策略接受23155包，1390K字节） pkts字节目标人选退出源目的地 链接INPUT（策略接受9个数据包，720个字节） pkts字节目标人选退出源目的地 链OUTPUT（策略ACCEPT 27包，1780字节） pkts字节目标人选退出源目的地 链POSTROUTING（策略ACCEPT 23173包，1392K字节） pkts字节目标人选退出源目的地 $ iptables -L -v 链INPUT（策略ACCEPT 13976包，1015K字节） pkts字节目标人选退出源目的地 Chain FORWARD（策略ACCEPT 241K包，24M字节） pkts字节目标人选退出源目的地 链接OUTPUT（策略ACCEPT 13946包，1119K字节） pkts字节目标人选退出源目的地
在一个DomUs上的iptables：
$ iptables -L -t nat -v 链PREROUTING（策略ACCEPT 53465包，2825K字节） pkts字节目标人选退出源目的地 链接INPUT（策略ACCEPT 53466包，2825K字节） pkts字节目标人选退出源目的地 链OUTPUT（策略ACCEPT 51527包，3091K字节） pkts字节目标人选退出源目的地 链POSTROUTING（策略ACCEPT 51527包，3091K字节） pkts字节目标人选退出源目的地 $ iptables -L -v 链接INPUT（策略ACCEPT 539K包，108M字节） pkts字节目标人选退出源目的地 链FORWARD（策略接受0包，0字节） pkts字节目标人选退出源目的地 连锁OUTPUT（策略ACCEPT 459K包，116M字节） pkts字节目标人选退出源目的地
我对这个有点好奇，对于你的症状find了很好的解释。 它们在nf_conntrack：table full中被很好地描述- 规则的缺失如何导致意外的行为 。
TL; DR：只是运行iptables -t nat -vnL开始加载nf_conntrack模块，导致无意的状态防火墙。 我还没有证实这一点，你可以打赌明天我会在工作中做对。
解决scheme：如果您不需要NAT，因为无论如何都要进行桥接，请卸载nf_conntrack_*模块以及所有依赖这些模块的依赖模块。 通过chkconfig ip[6]tables off防火墙将是一个好主意。
在Ubuntu中禁用防火墙可以通过sudo ufw disable来完成，如果不想重新启动，可以按照这些说明进行操作 。
Xen一定是NAT连接到你的domU服务器，并且连接的绝对数量压倒了内核跟踪他们的能力。 虽然可以通过增加nf_conntrack_max来增加分配给跟踪连接的空间，但是使用桥接networking而不是NAT可能会更好。 这样，domU服务器就可以获得自己的虚拟以太网卡，完全避免了这个问题。