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. On Fri, Nov 2, 2018 at 3:58 PM Ian Lance Taylor <i...@golang.org> wrote: > On Fri, Nov 2, 2018 at 2:29 PM, <m...@influxdata.com> wrote: > > > > 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. > > 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 > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
