linux – 为什么在Xen下TCP接受()性能如此糟糕？

发布时间：2020-12-13 18:40:38 所属栏目：Linux 来源：网络整理

导读：在Xen下,我的服务器可以接受()新的传入TCP连接的速度非常糟糕.裸机硬件上的相同测试显示3-5倍的加速. 在Xen下怎么会这么糟糕？您是否可以调整Xen以提高新TCP连接的性能？是否有其他虚拟化平台更适合这种用例？背景最近我一直在研究在Xen下运行的内部开发

在Xen下,我的服务器可以接受()新的传入TCP连接的速度非常糟糕.裸机硬件上的相同测试显示3-5倍的加速.

>在Xen下怎么会这么糟糕？
>您是否可以调整Xen以提高新TCP连接的性能？
>是否有其他虚拟化平台更适合这种用例？

背景

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

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

在裸机,非虚拟化平台上测试相同的场景时,我得到的测试结果显示TCP accept()速率超过35 000 /秒.这是在运行Ubuntu的Core i5 4核心机器上,所有内核几乎完全饱和.对我来说,那种形象似乎是正确的.

再次在Xen实例上,我尝试启用/调整sysctl.conf中的几乎所有设置.包括启用Receive Packet Steering和Receive Flow Steering以及将线程/进程固定到CPU但没有明显的增益.

我知道在运行虚拟化时可以预期降级性能.但到了这个程度？一种速度较慢的裸机服务器,性能优于virt. 8核5倍？

>这是Xen真正预期的行为吗？
>您是否可以调整Xen以提高新TCP连接的性能？
>是否有其他虚拟化平台更适合这种用例？

重现此行为

当进一步研究这个问题并查明问题时,我发现netperf性能测试工具可以模拟我遇到的类似情况.
使用netperf的TCP_CRR测试我收集了来自不同服务器(虚拟化和非虚拟化)的各种报告.如果您想提供一些调查结果或查看我当前的报告,请参阅https://gist.github.com/985475

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

>服务器已经在裸机硬件上进行了测试,它几乎使所有可用的内核饱和.
>使用保持活动的TCP连接时,问题就消失了.

为什么这很重要？

在ESN(我的雇主),我是Beaconpush的项目负责人,这是一个用Java编写的Comet / Web Socket服务器.即使它具有非常高的性能并且几乎可以在最佳条件下为其提供任何带宽,但它仍然受限于新TCP连接的速度.也就是说,如果您经常有大量用户流失,用户经常来去,那么就必须设置/拆除许多TCP连接.我们尽可能地减轻这种保持连接的速度.
但最终,accept()性能使我们的核心不再旋转,我们不喜欢这样.

更新1

有人posted this question to Hacker News,那里也有一些问题/答案.但我会尝试将这个问题与我发现的最新信息保持同步.

硬件/平台我测试过这个：

> EC2,实例类型为c1.xlarge(8核,7 GB RAM)和cc1.4xlarge(2x Intel Xeon X5570,23 GB RAM).使用的AMI分别是ami-08f40561和ami-1cad5275.有人还指出,“安全组”(即EC2s防火墙)也可能会受到影响.但是对于这个测试场景,我只尝试使用localhost来消除这种外部因素.我听到的另一个谣言是EC2实例不能超过10万PPS.
>两个运行Xen的私有虚拟化服务器.一个人在测试之前没有负载,但没有产生任何影响.
> Rackspace专用的Xen服务器.那里的结果差不多.

我正在重新运行这些测试并在https://gist.github.com/985475填写报告.如果您想提供帮助,请提供您的号码.这很简单！

(行动计划已移至单独的综合答案)

解决方法

现在：Xen下的小数据包性能很糟糕

(从问题本身转移到单独的答案)

根据HN(KVM开发人员？)上的用户的说法,这是由于Xen和KVM中的小数据包性能.这是虚拟化的一个已知问题,据他说,VMWare的ESX处理得更好.他还指出,KVM正在带来一些旨在缓解这一点的新功能(original post).

如果这是正确的,这个信息有点令人沮丧.无论哪种方式,我将尝试以下步骤,直到一些Xen大师带来明确的答案:)

来自xen-users邮件列表的Iain Kay编译了这个图：

注意TCP_CRR条,比较“2.6.18-239.9.1.el5”与“2.6.39(与Xen 4.1.0)”.

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

>按照syneticon-dj的建议,将此问题提交给特定于Xen的邮件列表和xensource的bugzilla
一个message was posted to the xen-user list,等待回复.
>创建一个简单的病态,应用程序级测试用例并发布它.已经创建了一个带有指令的测试服务器,published to GitHub.通过这种方式,你可以看到比netperf更真实的用例.>尝试使用32位PV Xen客户端实例,因为64位可能会导致Xen中的更多开销.有人在HN上提到了这一点.没有什么区别.>尝试在HN上按照abofh的建议在sysctl.conf中启用net.ipv4.tcp_syncookies.这显然可能会提高性能,因为握手会在内核中发生.我没有运气.>将积压从1024增加到更高的水平,这也是abofh对HN的建议.这也可能有所帮助,因为guest虚拟机可能会在dom0(主机)给出的执行切片期间接受()更多连接.>仔细检查所有机器上是否禁用了conntrack,因为它可以将接受率减半(由deubeulyou建议).是的,它在所有测试中都被禁用.>检查“监听队列溢出和netstat -s中的syncache桶溢出”(由HIK上的mike_esspe建议).>拆分多个核心之间的中断处理(RPS / RFS我试过先前尝试启用这个,但可能值得再次尝试).由亚当在HN推荐.>按照Matt Bailey的建议,关闭TCP分段卸载和分散/聚集加速. (在EC2或类似的VPS主机上不可用)

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!