On 2020-Jun-28 12:33:21 -0700, Donald Wilde <dwilde1 at gmail.com>
wrote:>On 6/28/20, Donald Wilde <dwilde1 at gmail.com> wrote:
>> On 6/27/20, Donald Wilde <dwilde1 at gmail.com> wrote:
>>> 'spinning rust' <haha> for a disk. My loader.conf has
>>> kern.maxswzone=4200000 and ccache is fully active and working for
both
>>> root on tcsh and users on sh.
Based on my calculations, that maxswzone is good for just under 1GB
swap. What do you see have for vm.swap_maxpages and vm.swzone?
>> Synth is still crashing hard, same issue.
>An update. Synth still crashed with one swap zone of 16GB.
What do you mean by "swap zone"? Do you mean you have one 16GB swap
device?
>stack overflow. As I say, there was no warning. Everything was fine,
>then memory usage went through the roof!
I've just tried building llvm80 via ports[1] on my laptop, using the
same options as you. I have 4GB RAM and 4GB swap with system defaults
and had no problems with an 8-way build. The highest swap usage I
noticed was <500MB. I suspect your problems are related to either
ccache or synth.
>The second one, hopefully, contains every log up to the one that
>crashed and hopefully also the beginning of that task. As I say, ONE
>builder and ONE task, after a reboot. LLVM80 was the only builder
>input.
"one builder and one task" - these are presumably synth terms since
they aren't standard ports building terms. You should be able to
do a single-theaded build of llvm80 in 4GB RAM without problems.
That said, I notice that the first log file suggests you were building
3 ports in parallel, and each port build was running 3 jobs - that's 9
jobs in parallel on a low-spec CPU with 4 threads. You should limit
the number of CPU-bound processes to the number of CPU threads you have.
[1] cd /usr/ports/devel/llvm80 && make
--
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL:
<http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20200630/9e7caf04/attachment.sig>