On Feb 24, 2025, at 00:36, Mark Millard <mark...@yahoo.com> wrote:

> On Feb 23, 2025, at 22:14, Yuri <y...@freebsd.org> wrote:
> 
>> On 2/23/25 21:46, Mark Millard wrote:
>>> What port/package?
>> 
>> finance/hyperswitch in arm64.
>> 
>> It builds in a very high memory (20GB) on amd64, which is probably what 
>> causes runaway builds on arm64.
> 
> For the bulk -ca with 14 builders for 14 VM cores on the M4 Max, each
> builder allowed: 14 processes :
> 
> 
> build of finance/hyperswitch | hyperswitch-2024.12.23.0_1 ended at 
> 2025-02-17T11:36:22-08:00
> build time: 01:14:38
> 
> 
> It likely had 13 other builders competing for cores over much of that time.
> By itself it would have taken less time. (High load averages.)
> 
> I could potentially force a rebuild by itself and monitor its RAM+SWAP use,
> which would be for the core count involved in my context. Also, the time
> scale factor would give a clue about the load average ratio.


Note: Context is UFS, not ZFS. So no ARC RAM use. USE_TMPFS=all

NOTE: hyperswitch is not in my TMPFS_BLACKLIST (yet?).

[00:00:49] [02] [00:00:00] Building   finance/hyperswitch | 
hyperswitch-2024.12.23.0_1
[00:24:44] [02] [00:23:55] Finished   finance/hyperswitch | 
hyperswitch-2024.12.23.0_1: Success ending TMPFS: 12.65 GiB

So: a little under 24 min when run by itself.


Various "MaxObs(erved)" figures are:

load averages:   . . . MaxObs:   9.86,   3.17,   1.76

Note: It spends lots of time under 1.5. It is not a
      heavily parallel type of processing.


Mem:  . . . 43057Mi MaxObsActive, 3103Mi MaxObsWired, 45479Mi 
MaxObs(Act+Wir+Lndry)
Swap: . . . 43057Mi MaxObs(Act+Lndry+SwapUsed),       45479Mi 
MaxObs(A+Wir+L+SU), 60897Mi (A+W+L+SU+InAct)

Note: The (A+W+L+SU+InAct) figure is from the MaxObs(A+Wir+L+SU) time frame
      instead of being a MaxObs figure.

Note: Lndry (L) always observed as 0; SwapUsed (SU) always observed as 0.
(Plenty of RAM.)

Note: it is unclear what the dirty vs. clean pages counts are for
the difference 60897Mi - 45479Mi. Clean pages could have been freed
based on RAM pressure otherwise.


So: up to possibly near 59.47+12.65 == 72.12 GiBytes of RAM+SWAP required.
But likely more than 44.41+12.65 == 57.06 GiByes of RAM+SWAP required.
That is for: USE_TMPFS=all
That might not match the official builders.

If I ran it with RAM at 40 GiBytes in the VM, then the RAM pressure would
make the RAM+SWAP figure have a much narrower range. But that should be
with a realistic USE_TMPFS status as well if such a test is made.

===
Mark Millard
marklmi at yahoo.com


Reply via email to