在Xen下为什么这么糟糕？
您可以调整Xen来提高新TCP连接的性能吗？
还有其他虚拟化平台更适合这种用例吗？内部开发的在Xen下运行的Java服务器。服务器会说HTTP并回答简单的TCP连接/请求/响应/断开连接呼叫。
但是即使向服务器发送大量流量，它每秒也不能接受超过7000个TCP连接。 8核EC2实例，c1.xlarge运行Xen）。在测试期间，服务器还表现出一种奇怪的行为，其中一个内核（不一定是CPU 0）的负载非常高，超过80％，而其他内核几乎保持空闲状态。这使我认为问题出在内核/底层虚拟化上。 000 /秒这是在运行Ubuntu的Core i5 4核心计算机上，所有核心几乎完全饱和。对我来说，这种感觉似乎是正确的。
在Xen实例上，我尝试启用/调整sysctl.conf中几乎所有的设置。包括启用“接收数据包控制”和“接收流控制”，以及将线程/进程固定到CPU，但没有明显的收益。但是到这个程度呢？较慢的裸机服务器胜过虚拟机。 8核是5的五分之一吗？
Xen确实是这种行为吗？还有其他虚拟化平台更适合这种用例吗？
重现此行为
在进一步调查并查明问题时，我发现netperf性能测试工具可以模拟我正在遇到的类似情况。非虚拟）。如果您想对某些发现做出贡献或查找我当前的报告，请参阅https://gist.github.com/985475
我怎么知道这个问题不是由于写得不好引起的软件吗？
该服务器已经在裸机硬件上进行了测试，并且几乎使所有可用内核饱和。
为什么这么重要？
在ESN（我的雇主），我是Beaconpush的项目负责人，Beaconpush是用Java编写的Comet / Web Socket服务器。尽管它的性能非常好，并且在最佳条件下几乎可以饱和分配给它的所有带宽，但是它仍然受到新TCP连接建立速度的限制。也就是说，如果用户频繁流失，那么用户来回频繁，则必须建立/删除许多TCP连接。我们尝试减轻这种影响，以保持连接尽可能长的时间。
但是最后，accept（）性能才是使我们的内核保持旋转的动力，我们不喜欢这样做。
更新1
有人将此问题发布到了Hacker News，那里也有一些问题/答案。但是，我将尝试不断更新这个问题，并提供我所获得的信息。 />实例类型为c1.xlarge（8核，7 GB RAM）和cc1.4xlarge（2x Intel Xeon X5570，23GB RAM）的EC2。使用的AMI分别为ami-08f40561和ami-1cad5275。有人还指出，“安全组”（即EC2防火墙）也可能会受到影响。但是对于此测试方案，我仅在本地主机上尝试过消除此类外部因素。我听到的另一个谣言是EC2实例的推送速度不能超过100k PPS。
两个运行Xen的私有虚拟服务器。在测试之前，其中一个负载为零，但没有影响。
Rackspace的专用Xen服务器专用。那里的结果大致相同。
我正在重新运行这些测试，并在https://gist.github.com/985475上填写报告。如果您想提供帮助，贡献您的数字。很简单！
（行动计划已移至单独的统一答案）
#1 楼
现在：Xen下的小数据包性能很糟糕（从问题本身移到一个单独的答案）根据HN上的用户（KVM开发人员？）这是由于Xen以及KVM中的小数据包性能所致。虚拟化是一个已知的问题，据他介绍，VMWare的ESX可以更好地处理这一问题。他还指出，KVM带来了一些旨在缓解这种情况的新功能。（
如果正确，此信息会令人沮丧。无论哪种方式，我都将尝试以下步骤，直到出现一些Xen专家并给出明确的答案为止：） />注意TCP_CRR栏，将“ 2.6.18-239.9.1.el5”与“ 2.6.39（使用Xen 4.1.0）进行比较”。并且来自HN：
将此问题提交给特定于Xen的邮件列表，并按syneticon-dj的建议将xensource的bugzilla提交给
将消息发布到xen用户列表，等待回复。
创建一个简单的，病理的，应用程序级的测试用例并发布。已经创建了带有说明的测试服务器，并将其发布到GitHub。与此相比，与netperf相比，您应该能够看到更实际的用例。
尝试使用32位PV Xen来宾实例，因为64位可能会导致Xen产生更多开销。有人在HN上提到了这一点。没什么大不了。由于握手会在内核中进行，因此这显然可以提高性能。我对此没有运气。
将积压从1024增加到更高的水平，这同样由HN的abofh提出。这也可能有所帮助，因为guest虚拟机在由dom0（主机）指定的执行片中可能接受（）更多连接。
仔细检查conntrack是否在所有计算机上都已禁用，因为它可以使接受率减半（由deubeulyou建议）。是的，它在所有测试中都被禁用。
检查“ netstat -s中的监听队列溢出和同步桶溢出”（由HN上的mike_esspe建议）。我尝试过启用的RFS应该可以这样做，但是值得再次尝试）。由HN的adamt建议。
根据Matt Bailey的建议，关闭TCP分段卸载和分散/聚集加速。 （在EC2或类似的VPS主机上不可能）
评论
发现后+1发布性能结果！
–chrisaycock
11年5月23日在0:47
有人在Twitter上向我问了这个问题。不幸的是，似乎这个问题仍然存在。自去年以来，我没有做太多研究。我不知道Xen在这段时间内可能有所改善。 KVM开发人员还提到他们正在解决此类问题。可能值得追求。另外，我听到的另一个建议是尝试使用OpenVZ而不是Xen / KVM，因为它会增加或减少对系统调用的分层/拦截。
– cgbystrom
2012-03-20 8:52
#2 楼
有趣的是，我发现关闭NIC硬件加速可以大大改善Xen控制器上的网络性能（LXC也是如此）：>
TCP分段卸载：
/usr/sbin/ethtool -K br0 sg off br0是虚拟机管理程序主机上的网桥或网络设备。您必须将其设置为在每次启动时将其关闭。 YMMV。
评论
我第二。我有一台运行在Xen上的Windows 2003服务器，在高吞吐量条件下遇到了一些可怕的丢包问题。当我禁用TCP段卸载时，问题消失了
– rupello
2011年5月22日19:24
谢谢。我用您的建议更新了原始问题中的“行动计划”。
– cgbystrom
11年5月22日在21:39
另请参阅cloudnull.io/2012/07/xenserver-network-tuning
–拉里（Lari Hotari）
2014年10月10日在7:34
我想知道：这是经典的“吞吐量与响应时间”吗？仅计算接受率，此处的“响应时间”可能就是“吞吐量”，但是对于大型数据传输，情况可能有所不同（我想）。
– U. Windl
20年11月2日在8:07
#3 楼
也许您可以澄清一下-您是在自己的服务器上还是仅在EC2实例上在Xen下运行测试？Accept只是另一个系统调用，而新的连接只是在前几个数据包中具有一些特定的标志而不同-像Xen这样的虚拟机管理程序绝对不应看到任何区别。设置的其他部分可能：例如，在EC2中，如果安全组与此有关，我不会感到惊讶；据报道，conntrack还可以将新连接的接受率减半（PDF）。
最后，似乎存在CPU /内核组合，导致EC2上的CPU使用率/挂起状态异常（一般来说Xen），最近由Librato发表。
评论
我更新了问题，并阐明了尝试使用哪种硬件。 Abofh还建议将积压量增加到1024以上，以加快来宾执行片期间可能的accept（）数量。关于conntrack，我绝对应该仔细检查这些东西是否被禁用，谢谢。我已经读过Liberato的文章，但鉴于我尝试过使用的不同硬件数量，事实并非如此。
– cgbystrom
2011年5月22日20:57
要注意的一件事是，在PVM Xen下，来宾加载数仅说明了一半：通常，您也必须监视虚拟机监控程序的加载数。专门查看来宾中的（窃听率）（/ proc / stat中的字段8）（这很新（自从Linux 2.6.11开始添加））。
– U. Windl
20年11月2日，8：13
#4 楼
确保在dom0的桥接代码中禁用了iptables和其他挂钩。显然，它仅适用于桥接网络Xen设置。 dom0并将其固定。系统管理程序引导选项：echo 0 > /proc/sys/net/bridge/bridge-nf-call-ip6tables
echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables
echo 0 > /proc/sys/net/bridge.bridge-nf-call-arptables
您是否尝试过将物理以太网PCI设备传递给domU？应该有不错的性能提升。
评论
指出问题的出色工作，但我相信在Xen特定的邮件列表，支持论坛甚至xensource错误报告站点上，您会得到更好的服务。我相信这可能是一些调度程序错误-如果您使用7,000个连接数* 4核/ 0.80 CPU负载，您将得到35,000-当4核完全饱和时将得到的数字。嗯，还有另一件事：如果可以，请为您的来宾尝试一个不同的（也许是较新的）内核版本。
@ syneticon-dj谢谢。我在内核为2.6.38的EC2上的cc1.4xlarge上进行了尝试。如果我没记错的话，我看到了约10％的增长。但这更有可能是由于该实例类型的硬件更加强大。
感谢您及时更新HN的回复，这是一个很好的问题。我建议将行动计划转变为一个统一的答案，因为这些都是解决问题的可能。
@jeff移动行动计划，检查。