Make sure you set GOMAXPROCS when the runtime is cgroup limited.<p>I once profiled a slow go program running on a node with 168 cores, but cpu.max was 2 cores for the cgroup. The runtime defaults to set GOMAXPROCS to the number of visible cores which was 168 in this case. Over half the runtime was the scheduler bouncing goroutines between 168 processes despite cpu.max being 2 CPU.<p>The JRE is smart enough to figure out if it is running in a resource limited cgroup and make sane decisions based upon that, but golang has no such thing.
It's always a sign of good design when something as complex as the scheduler described "just works" with the simple abstraction of the goroutine. What a great article.<p>"1/61 of the time, check the global run queue."
Stuff like this is a little odd; I would have thought this would be a variable dependent on the number of physical cores.