我们有一个构建系统,直到数周前,每个目标设备的完整构建大约需要1.5个小时。
在某些时候,这个时间增加了约3.5个小时,由于我们为大约9个不同的目标进行了构建,因此将构建时间从14个小时增加到了32个小时。
我们认为我们终于确定了问题所在。我在Win10机器(来宾为Ubuntu 16.04)上运行的VM已复制到Win7机器。 VM的设置,运行的磁盘类型等均未更改。机器的配置也非常类似(相同的CPU,磁盘等)。顺便说一句,我最初运行VirtualBox 5.x,而Win7机器具有6.0.12,但我不认为这是问题,因为我的机器上升级到6.0.14并没有改变。即使将VM磁盘移动到我盒子上的SSD上,也没有什么缓解,这意味着几乎可以肯定它受CPU限制。
运行VM的Win7盒在大约1.5个小时内完成了每个构建。
然后我们对该框所做的
only
更改是对Win10的就地升级,瞧瞧,这些构建现在每个都需要花费3.5个小时。[>[一项研究表明,有几个人在将VirtualBox / Win10作为主机和来宾时遇到问题,但是给出了建议(视频内存增加,主机和来宾之间CPU /内存的重新平衡,启用/禁用视频加速,等)似乎无法解决任何问题。我们正在考虑一些想法,例如:在裸机上运行Ubuntu,但这显然使移动VM更加困难;
[当使用Gibson Research InSpectre工具关闭缓解措施时(当然,为了安全起见,对机器进行了气密密封之后,构建再次降低到每个目标一个半小时。
现在,我们只需要弄清楚如何继续进行下去。我们可能必须在已经准备好源代码的气隙式机器上构建。
一些其他细节。我们所有的开发人员机器都为CPUID 306c3 Haswell
,这是缓解措施尤其遭受的打击。我们将在更现代的处理器CPUID 810f10
(AMD Ryzen 5)上进行测试,以查看影响是否较小。
希望这将是最终更新。尽管我们最初通过在Windows
进一步的调查似乎表明,尽管VirtualBox在这种环境中遭受了损失,但VMware却没有。因此,我们一直在寻找可以解释差异的方法。
最终,我们遇到了this thread,它描述了一个类似的问题,并且在那里尝试一种建议的解决方案时,我们发现我们可以重新获得速度[[而没有损害主机OS。解决方案是在关闭(不挂起)VM的同时运行以下命令:
vboxmanage modifyvm VM_NAME --spec-ctrl on
其中VM_NAME
应替换为您的实际VM名称(通过vboxmanage list vms
获得)。然后,在重新启动VM之后,它应该再次以正常速度运行。
[不幸的是,这意味着我为整个开发团队购买新的Threadripper PC的商业案例现在已经崩溃。该死的,互联网:-)