Also, I see two buildbot VMs with 9 GB of memory allocated: OS X El Capitan v10.11.6 (15G22010) Xcode v8.2.1 (8C1002) Apple LLVM version 8.0.0 (clang-800.0.42.1) Architecture: x86_64 C++ library: libc++ CPU: 8 ⨉ 2.15 GHz RAM: 9 GB Boot date: 2021-05-01T21:54:00Z
macOS Mojave v10.14.6 (18G9028) Xcode v10.3 (10G8) Apple LLVM version 10.0.1 (clang-1001.0.46.4) Architecture: x86_64 C++ library: libc++ CPU: 8 ⨉ 2.15 GHz RAM: 9 GB Boot date: 2021-05-01T21:54:00Z This is problematic, if we’re already exceeding the physical memory available [when also factoring in the needs of the hypervisor]. > On 2021-05-17-M, at 18:30, Christopher Nielsen <[email protected]> > wrote: > > If you total up the memory allocated across all VMs, is there at least one or > two GB free for the hypervisor? > >> On 2021-05-17-M, at 18:26, Ryan Schmidt <[email protected]> wrote: >> >>> On May 17, 2021, at 07:36, Christopher Nielsen wrote: >>> >>> As for overcommitment: I’m simply suggesting that we reduce the number of >>> vCPUs per builder, from eight to six. >> >> And I'm suggesting that doing so will slow things down in those situations >> when only one or two VMs on a host are busy. >> >> If I reduce the number of vCPUs from 8 to 6, then there would be 2 GB extra >> RAM per VM in each server that I could move elsewhere. >> >>> Otherwise, the formula MacPorts base uses to calculate builds jobs and such >>> is fine as-is, and I’m not advocating that we change it.
