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是否能突破瓶颈呢？把群辉的直通网卡删除，并使用虚拟网卡接回虚拟交换机后，首先使用迅雷测试

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

下面使用Aria2

可见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资源给上述瓶颈呢？结果证明有一定效果，但是效果不明显

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

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

结论2

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