roups.com [mailto:
> golan...@googlegroups.com ] *On Behalf Of *r...@golang.org
>
> *Sent:* 2016 December 30, Fri 09:53
> *To:* golang-nuts
> *Subject:* [go-nuts] Re: too many runtime.gcBgMarkStartWorkers ?
>
>
>
> The default is GOMAXPROCS == numCPU and the runtim
to
do some scheduling for them.
John
John Souvestre - New Orleans LA
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On
Behalf Of r...@golang.org
Sent: 2016 December 30, Fri 09:53
To: golang-nuts
Subject: [go-nuts] Re: too many runtime.gcBgMarkStartWork
The default is GOMAXPROCS == numCPU and the runtime is optimized and tested
for this. There are use cases involving co-tenancy where setting GOMAXPROCS
< numCPU tells the OS to limit HW allocation and improves overall
throughput when several programs are running concurrently.
Setting GOMAXPROC
There may be a bug here. IMO the runtime should never try to start more that
numCPUs background workers regardless of the size of GOMAXPROCS as that'll just
cause contention during the GC cycle.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
Thanks Dave, we do set the GOMAXPROCS to 64. thanks for explanation.
On Wednesday, December 28, 2016 at 12:06:42 AM UTC-8, Ganesh Sangle wrote:
>
> Hi,
> While examining the stack trace from a crash where the process seems to
> have become extremely slow, I see a lot of these goroutines:
>
> g
On Wednesday, 28 December 2016 19:06:42 UTC+11, Ganesh Sangle wrote:
>
> Hi,
> While examining the stack trace from a crash where the process seems to
> have become extremely slow, I see a lot of these goroutines:
>
> goroutine 66 [mark worker (idle)]:
> runtime.gopark(0x2cf6cf0, 0xc820d1, 0
