ESXI allinone 黑群辉迅雷下载无法满速排查

背景

OpenWRT接直通网卡拨号,黑群辉和OpenWRT通过ESXI的虚拟交换机连在一起,虚拟交换机通过管理口(非直通),级联了外部交换机:一台AP模式下的硬路由。PC和手机通过与AP连接。宿主机配置:i5 3317u、8G、128G。

家里宽带500M,可是黑群辉里的迅雷开了会员,依然只能跑到100M+的下载速度。从ESXI管理界面看,此时CPU满载。

群辉接到外部硬交换机上

但是PC上的测速可以跑满带宽,迅雷下载也能跑满。首先怀疑是虚拟交换机造成的性能瓶颈,于是将闲置的一个网口,直通给群辉,删除了群辉原先的那个虚拟网卡,并将直通的网卡,接入外部的硬路由充当的交换机。这样黑群辉和PC的拓扑就一样了,结果测试结果依然没变。

仔细一想,虽然PC和黑群辉此时接着硬交换机,可是硬交换机是级联在ESXI的虚拟交换机上的呀,依然会通过虚拟交换机消耗性能,而PC是能跑满带宽的,所以瓶颈不是出在虚拟交换机上。与实验结果一致。

不使用ESXI内的OpenWRT拨号和NAT,群辉接到外部硬路由上

从上图可以看出,此时OpenWRT也是耗费了很大的资源。于是我拿了台硬路由拨号,直接将群辉的直通网卡接到硬路由的LAN上,继续使用迅雷下载。果然此时下载速度突破了之前的100M,在300M-500M之间徘徊,而宿主机的资源还没被耗尽。

此时已经差不多能得出结论了:单独用外部PC迅雷下载、单独使用ESXI中的黑群辉迅雷下载,都达不到瓶颈,而虚拟的黑群辉通过通过虚拟交换机连接虚拟的OpenWRT迅雷下载时,群辉中迅雷的高CPU占用,使OpenWRT或者ESXI(虚拟交换机)无足够的资源,达到了CPU瓶颈,最终速度只有100M+了。

使用Aria2替代迅雷做对照实验

既然迅雷这么占CPU,那么使用Aria2是否能突破瓶颈呢?把群辉的直通网卡删除,并使用虚拟网卡接回虚拟交换机后,首先使用迅雷测试

迅雷下载时的性能消耗,左上左下右上右下下,分别为OP、OP、DSM、DSM、ESXI
宿主机的CPU几乎跑满,迅雷下载速度在100M+

可见迅雷占用了群辉绝大多数的CPU资源,稳定的使用了群辉222%左右的CPU。宿主机资源几乎用完,速度只有100M+。

下面使用Aria2

Aria2下载时的性能消耗,左上左下右上右下下,分别为OP、OP、DSM、DSM、ESXI
宿主机的性能没跑满,但是Aria2的速度已经到300M+了

可见Aria2对群辉的CPU占用,明显低于迅雷。我用的esir这个summer版本的固件有performance issue,软中断(ksoftirqd)会占用很高CPU,同时由于82574L在OpenWRT下用的e1000e driver,不支持Receive Side Scaling(RSS),所以一核干活三核围观。结合上图中OpenWRT接近25%的资源占用,所以我认为OpenWRT此时也达到了瓶颈。群辉不高的资源占用+OpenWRT有更多的资源且达到瓶颈,使得Aria2的下载速度可以接近带宽了。这更加坐实了上述迅雷导致CPU瓶颈的推论。

结论

群辉下的迅雷极度占用CPU,3代i5压不住,可通过升级CPU,或者使用Aria2替代迅雷,突破CPU瓶颈。

思考

如果群辉不使用4个vCPU,改成3个或者2个,是否有助于让渡更多CPU资源给上述瓶颈呢?结果证明有一定效果,但是效果不明显

迅雷依然吃掉了三个vCPU中的大部分资源
宿主机的CPU资源被用完了

迅雷下载速度并没有改观,群辉内部的CPU占用率上升了,不过速度也没下降。于是继续改成只给群辉2个vCPU(OpenWRT也从4个vCPU改成2个,且实验时是几天后,OpenWRT已经出现软中断占用过高的问题)

迅雷吃掉了2个vCPU的大部分资源
速度比之前快了
宿主机资源不像之前持续100%

此时由于迅雷对宿主机的资源占用有限,宿主机有更多资源给OpenWRT,速度反而上升。

结论2

可见迅雷不管给多少个核心,都是吃满,而且对速度还没有贡献。由于我的CPU是双核四线程,所以实际上只有两个物理核心。而ESXI会优先将任务在不同的物理核心之间分配,所以分别给DSM和OpenWRT两个vCPU的话,就能做到DSM和OpenWRT中繁重的任务,分别落在两个不同的物理核中,而不会因为DSM中迅雷对CPU的极端占用,影响了OpenWRT。

Share

You may also like...

13 Responses

  1. 匿名说道:

    迅雷+btrfs+机械盘,btrfs的内核线程CPU占用巨高,如果是ext4的任意盘或者btrfs的SSD就没事

    • 匿名说道:

      如果内存不足btrfs就会一直flush,所以需要巨大量内存才能保持和ext4一样的写入性能,实在是太糟糕了

  2. wlf2w说道:

    我这边也是同样的问题,迅雷一开始下载就cpu占用就蹭蹭蹭上去,基本都在百分九十左右

  3. vinson023说道:

    今天又装了一台黑群硬件配置比之前更低,同样ESXI下部署,然而这次我用了ext4分区而不是之前的brtfs分区,然后居然发现所有的问题迎刃而解,迅雷终于满速下载了。

    • TronMaster说道:

      我的也是btrfs文件系统,看来是迅雷对btrfs的兼容问题。。而且高版本迅雷还做了负优化🤣你换成ext4后,满速下载的时候CPU占用高吗?如果白裙也有这个问题,奇怪为什么迅雷没有重视,网上也很少相关讨论。

      • vinson023说道:

        最终发现新版迅雷还是有些问题,下载一开始CPU被拉到很高频率这个时候可以满速下载,然后几秒钟之后CPU降了但是下载速度同样也降了,所以最后还是得用回老版本的迅雷。

        • TronMaster说道:

          逐渐放弃用迅雷下载到本地NAS了,群辉上迅雷体验太不好了,主力用AList挂载阿里网盘看片

  4. vinson023说道:

    我的E3 1240一样的,CPU迅雷占用非常高,根本跑不到慢速,ARIA2就没有问题。

    • TronMaster说道:

      我同事的白裙据说正常,迅雷可以轻松跑满带宽,白裙的硬件配置还更低,所以觉得奇怪

      • vinson023说道:

        我这两天又找了一台物理黑群也是一样最高速度不会超过50MB/S,一般最高速度都是在四十几MB/S左右,有时候会更慢,我记得最早我没有升级7.0的时候好像可以跑满带宽的,后面再试下6.2跑迅雷。

      • vinson023说道:

        今天试了下白群916+ DSM7.2 一样无法满速下载

      • vinson023说道:

        最终我找了一个迅雷1.7.2的版本其下载速度可以一直稳定在50-60MB/s左右,如果用最新版的3.8版和之前的2.8版只有10几MB/s的下载速度,虽然CPU占用依然很高但是至少下载速度稳定住了,这足以证明迅雷是在做负优化。

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注