4
在Xen下，为什么TCP accept（）性能如此糟糕？
在Xen下，我的服务器可以接受（）新的传入TCP连接的速率确实很差。在裸机硬件上进行的相同测试显示速度提高了3-5倍。 在Xen下怎么这么糟糕？ 您可以调整Xen来提高新TCP连接的性能吗？ 是否有其他虚拟化平台更适合此类用例？ 背景 最近，我一直在研究在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倍？ Xen确实是这种预期的行为吗？ 您可以调整Xen来提高新TCP连接的性能吗？ 是否有其他虚拟化平台更适合此类用例？ 重现此行为 在进一步调查并查明问题时，我发现netperf性能测试工具可以模拟我遇到的类似情况。使用netperf的TCP_CRR测试，我从不同的服务器（虚拟服务器和非虚拟服务器）收集了各种报告。如果您想对某些发现做出贡献或查找我当前的报告，请参阅https://gist.github.com/985475 我怎么知道这个问题不是由于软件写得不好？ 该服务器已经在裸机硬件上进行了测试，并且几乎饱和了所有可用内核。 使用保持活动的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上填写报告。如果您想提供帮助，请贡献您的数量。这很容易！ （行动计划已移至单独的综合答案中）