Use uber-go/automaxprocs to default GOMAXPROCS aware of Linux CPU Quotas

[BenTheElder]

See:

• runtime: make GOMAXPROCS cfs-aware on GOOS=linux golang/go#33803
• Use single CPU for building site preview kubernetes/website#41142

Basically: When using hugo in a container with limited CPU quota, hugo can encounter CPU throttling issues because GOMAXPROCS is defaulted to the underlying hardware core count instead of the allocated CPU limits in the container.

There's something of a defacto standard library for defaulting this in a CPU limit aware way in https://github.com/uber-go/automaxprocs, at least until golang/go#33803 is solved.

Users would still be able to override by setting GOMAXPROCS env, and this is a fairly small MIT licensed dependency.

[bep]

A note from the sideline, Hugo bases its parallelism on

1. HUGO_NUMWORKERMULTIPLIER env var if set
2. runtime.NumCPU()

So, setting HUGO_NUMWORKERMULTIPLIER=1 (or something) could be a workaround.

[BenTheElder]

Ack, thanks!

We're getting good results setting GOMAXPROCS=1 in netlify for Kubernetes (it appears free netlify has ~1 core allocated?)

runtime.NumCPU()

I think it might? be better to base it on runtime.GOMAXPROCS(0) (<1 does not set it and only returns the current value).

Even without that though, AIUI the setting GOMAXPROCS will let go internally do better at scheduling within the CPU quota.

I filed a sample PR in #10951 for the latter, we've seen automaxprocs fix performance issues with containerized Go more generally, e.g. in Kubernetes's CI unit tests.

[bep]

I needed to revert this; a new patch that makes the tests pass is welcomed, but I have not time to investigate this at the moment.

[BenTheElder]

I'll look into that 👀

Thank you for all your work on hugo!

[bep]

Great; Ideally I would want no output from that library.

[BenTheElder]

OK, sorry about that, the root automaxprocs just calls maxprocs.Set(macprocs.Logger(log.Printf)), if we call maxprocs.Set() instead there will be no logging this time (per the godocs, checking the implementation, and local testing).

I can repro the failures locally on the last PR from undesired added logging.
go test ./... passes with the updated patch, I should've thought to check before filing the last PR.

Filed #10952

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.