我们拥有一个构建系统,直到几周前,整个目标设备的完整构建大约需要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个小时。
然后,我们对该框进行的仅 更改是对Win10的就地升级,并且瞧,构建现在也 花费3.5个小时。
一些研究表明,有几个人同时将VirtualBox / Win10作为主机和来宾有问题,但是给出了建议(视频内存增加,主机和来宾之间CPU /内存的重新平衡,启用/禁用视频加速)等等)似乎无法解决任何问题。
我们正在考虑一些想法,例如:
- 在裸机上运行Ubuntu,但这显然使移动VM更加困难;
- 在 Linux 主机上运行这些Ubuntu来宾,因此,假设问题是Win10,我们在提高性能的同时仍允许VM移动性;
- 坚持使用Win10,但使用VMWare Player而不是VirtualBox(当前正在测试以查看是否可行);
- 将构建框恢复为Win7,但我认为IT部门不会对该提案感到满意(即,在批准该提议的过程中,它并不寄予希望:-))。
有人对前进的方式有其他想法吗?