How can I identify the default value of the -p build flag?

[ma...@influxdata.com]

This is somewhat an XY problem, so let me preface with the X:

We infrequently see `/usr/local/go/pkg/tool/linux_amd64/link: signal: killed` when running `go test` for our project on CircleCI, running Go 1.11.1.

As far as I can tell, that killed signal is due to OOMing. The comment at https://github.com/golang/go/issues/26186#issuecomment-427482208 says he worked around that same symptom by using -p=8.

I could easily switch our command to `go test -p=8`, but I want to understand what value is used when the -p flag isn't provided.

All `go help build` has to say is:

> -p n

> the number of programs, such as build commands or

> test binaries, that can be run in parallel.

> The default is the number of CPUs available.

Our particular build seems to fall under this part of the Circle docs: https://circleci.com/docs/2.0/configuration-reference/#resource_class

I think we're on a 2 vCPU setup, but the docs go on to state:

> Java, Erlang and any other languages that introspect the /proc directory for information about CPU count may require additional configuration to prevent them from slowing down when using the CircleCI 2.0 resource class feature. Programs with this issue may request 32 CPU cores and run slower than they would when requesting one core. Users of languages with this issue should pin their CPU count to their guaranteed CPU resources.

Skimming through the code, it looks like Go on Linux should be using sched_getaffinity, so I don't think it's inspecting /proc. But maybe I read things wrong.

Is the `go help build` output "number of CPUs available" GOMAXPROCS or something else? I was somewhat surprised to see that `go env` doesn't emit GOMAXPROCS.

I also tried locally running `go test -x` to see if that had any output to hint towards what the default value of -p would be, but if that detail was in the output, I missed it.

[Ian Lance Taylor]

To see the default value used for the -p option, run this program:

package main

import (
"fmt"
"runtime"
)

func main() {
fmt.Println(runtime.NumCPU())
}

Ian

[Mark Rushakoff]

Thanks. That confirms that Go thinks there are 36 CPUs available in that environment. 

I'm still a bit surprised that there's no way to invoke the go executable to get the value of runtime.NumCPU. A quick grep through src/cmd looks like it isn't directly exposed anywhere. I might file an issue requesting that to be exposed, but I'll think on it a bit first.