Quick status update, though there's not a "finished" result/conclusion yet.
Recreated the VM last night, giving it 4 cpu's, 65GB of space on root (/), and 8GB of swap. Used UFS instead of ZFS so ARC wouldn't be grabbing memory.
Allocated 12GB of ram to the VM, which was probably too much. VMware Fusion didn't complain, but the (host) system (my desktop) acted weirdly. Suspecting it may have caused too much contention on the host, so I'd better stick with 10-11GB or so instead from here on.
UFS vs ZFS though... not a clear result yet due to something strange. Over the last few days when using ZFS I'd allocated the VM 50GB of space (not including swap) to build in. No issues with space. Last night though, with 65GB of space (as UFS), the build failed. The VM ran out of space.
Not sure if it's due to the UFS change, or if the code update in FreeNAS itself caused it. I'm suspecting it was the large change in FreeNAS code base, but not sure.
Some graphs (from Zabbix server installed last night too), showing the stats which seem relevant. The missing stats chunk from about 10:30-11:45 was when the host filesystem the VM is on also ran out of space. ;) VMware paused the VM and popped up a warning which I didn't notice until I came back.
As expected, CPU is pretty much 100% for all of the compile phases.
This shows free disk space. Starts out ~60GB, and continues into the ground/failure. ;)
This shows the amount of free swap space. With 12GB of RAM, and 8GB of swap, the compile process (in this failed run) didn't get very far into swap. Not even 1 GB used. A full (successful) run may be different.
Memory usage. There seems to be only one significant section of memory pressure, ~08:00am to ~08:45am. That timeframe corresponds to the only significant swap usage period in the graph above. At a rough guess, it's probably during either the buildworld or buildkernel phase, rather than during the lengthy port building which comes after.
If we want to reduce memory usage, we could probably look into environment variables affecting buildworld/buildkernel. Maybe something to limit the # of threads there, similar to what POUDRIERE_JOBS does for port building.
Network traffic. The initial download of packages and source near the start, and not much after that:
Tonight I'll try the whole run again, with maybe 100GB free disk (UFS), 11GB RAM, and 4 cpus. Hopefully that runs to completion ok. ;)