在Xen下，我的服务器可以接受（）新的传入TCP连接的速率确实很差。在裸机硬件上进行的相同测试显示速度提高了3-5倍。

1. 在Xen下怎么这么糟糕？
2. 您可以调整Xen来提高新TCP连接的性能吗？
3. 是否有其他虚拟化平台更适合此类用例？

背景

最近，我一直在研究在Xen下运行的内部开发Java服务器的一些性能瓶颈。服务器使用HTTP并回答简单的TCP连接/请求/响应/断开连接呼叫。

但是，即使在向服务器发送大量流量时，它每秒也不能接受超过7000个TCP连接（在8核EC2实例上，运行Xen的c1.xlarge）。在测试过程中，服务器还表现出一种奇怪的行为，其中一个内核（不一定是cpu 0）的负载超过80％，而其他内核几乎保持空闲状态。这使我认为问题与内核/底层虚拟化有关。

在裸机，非虚拟平台上测试相同的方案时，我得到的测试结果显示，TCP accept（）的速率超过35000 /秒。这是在运行Ubuntu的Core i5 4核心计算机上，所有核心几乎完全饱和。在我看来，这种数字是正确的。

再次在Xen实例上，我尝试启用/调整sysctl.conf中几乎所有的设置。包括启用“ 接收数据包控制”和“ 接收流控制”以及将线程/进程固定到CPU，但没有明显的收获。

我知道运行虚拟化时性能会下降。但是到这个程度呢？较慢的裸机服务器胜过虚拟机。8核心减少了5倍？

1. Xen确实是这种预期的行为吗？
2. 您可以调整Xen来提高新TCP连接的性能吗？
3. 是否有其他虚拟化平台更适合此类用例？

重现此行为

在进一步调查并查明问题时，我发现netperf性能测试工具可以模拟我遇到的类似情况。使用netperf的TCP_CRR测试，我从不同的服务器（虚拟服务器和非虚拟服务器）收集了各种报告。如果您想对某些发现做出贡献或查找我当前的报告，请参阅https://gist.github.com/985475

我怎么知道这个问题不是由于软件写得不好？

1. 该服务器已经在裸机硬件上进行了测试，并且几乎饱和了所有可用内核。
2. 使用保持活动的TCP连接时，问题消失了。

为什么这很重要？

在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防火墙）也可能会受到影响。但是对于此测试方案，我仅在localhost上尝试过消除此类外部因素。我听到的另一个谣言是，EC2实例的推送速度不能超过100k PPS。
• 两个运行Xen的私有虚拟服务器。在测试之前，一个负载为零，但没有影响。
• Rackspace的专用Xen服务器专用。大约有相同的结果。

我正在重新运行这些测试，并在https://gist.github.com/985475上填写报告。如果您想提供帮助，请贡献您的数量。这很容易！

（行动计划已移至单独的综合答案中）

现在：Xen带来小数据包性能下降

（从问题本身移至单独的答案）

根据HN的用户（KVM开发人员？）的说法，这是由于Xen以及KVM的小数据包性能所致。虚拟化是一个已知的问题，据他介绍，VMWare的ESX可以更好地解决这一问题。他还指出，KVM带来了一些旨在缓解这种情况的新功能（原始帖子）。

如果正确，此信息会令人沮丧。无论哪种方式，我都将尝试以下步骤，直到出现一些Xen专家并给出明确的答案为止：）

来自xen-users邮件列表的Iain Kay编译了此图： 注意TCP_CRR条，将“ 2.6.18-239.9.1.el5”与“ 2.6.39（使用Xen 4.1.0）进行比较”。

基于此处和HN的答复/答案的当前行动计划：

1. 按照syneticon-dj的建议，将此问题提交到特定于Xen的邮件列表和xensource的bugzilla。 一条消息已发布到xen-user列表，等待回复。

2. 创建一个简单的，病理的，应用程序级的测试用例并发布。
   带有说明的测试服务器已创建并发布到GitHub。这样，与netperf相比，您应该能够看到更多实际的用例。

3. 尝试使用32位PV Xen来宾实例，因为64位可能会导致Xen中更多的开销。有人在HN上提到了这一点。没有改变。

4. 尝试按照HN上的abofh的建议在sysctl.conf中启用net.ipv4.tcp_syncookies。由于握手会在内核中进行，因此这显然可以提高性能。我没有运气。

5. HN上的abofh也建议将积压从1024增加到更高。这也可能会有所帮助，因为guest虚拟机在由dom0（主机）指定的执行片中可能接受（）更多连接。

6. 仔细检查conntrack是否在所有机器上都已禁用，因为它可以使接受率减半（由deubeulyou建议）。是的，它在所有测试中都被禁用。

7. 检查“ netstat -s中的监听队列溢出和同步桶溢出”（由HN上的mike_esspe建议）。

8. 在多个内核之间分配中断处理（我曾尝试启用的RPS / RFS应该可以这样做，但值得再次尝试）。由HN的adamt建议。

9. 按照Matt Bailey的建议，关闭TCP分段卸载和分散/聚集加速。（在EC2或类似的VPS主机上不可能）

有趣的是，我发现关闭NIC硬件加速可以极大地提高Xen控制器上的网络性能（LXC也是如此）：

散布式电池

/usr/sbin/ethtool -K br0 sg off

TCP分段卸载：

/usr/sbin/ethtool -K br0 tso off

其中br0是管理程序主机上的网桥或网络设备。您必须将其设置为在每次启动时将其关闭。YMMV。

也许您可以澄清一下-您是在Xen上是在自己的服务器上还是仅在EC2实例上运行测试？

Accept只是另一个系统调用，新的连接只是在前几个数据包中具有一些特定的标志而有所不同-像Xen这样的虚拟机管理程序绝对不应该有任何区别。设置的其他部分可能：例如，在EC2中，如果安全组与此有关，我不会感到惊讶；据报道 conntrack还将新连接接受率减半（PDF）。

最后，就像Librato最近在博客中提到的那样，似乎有一些CPU /内核组合导致EC2上的CPU使用率过高/挂断（通常可能是Xen）。

确保在dom0的桥接代码中禁用了iptables和其他挂钩。显然，它仅适用于桥接网络Xen设置。

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

它取决于服务器的大小，但取决于较小的服务器（4核处理器），它会将一个CPU内核专用于Xen dom0并将其固定。系统管理程序引导选项：

dom0_max_vcpus=1 dom0_vcpus_pin dom0_mem=<at least 512M>

您是否尝试过将物理以太网PCI设备传递给domU？应该有不错的性能提升。