4 ms·
Well specifically it would be cool if it counted the optimal number to set GOMAXPROCS to, since I think that's like the main use of runtime.NumCPU().
by nulltype 11y ago
Well specifically it would be cool if it counted the optimal number to set GOMAXPROCS to, since I think that's like the main use of runtime.NumCPU().
- thrownaway2424 11y agoRight. Currently runtime.NumCPU tries to be fancy by looking at the population count of the cpuset mask[1]. However in a hosted environment using containers there's no reason to believe that the cpuset will remain fixed over the life of the process. This can undercount the available CPUs, leaving you with a GOMAXPROCS that is too low. 1: https://code.google.com/p/go/source/browse/src/pkg/runtime/thread_linux.c?r=ef1158a7371796bf4823a1ce43e3d01d2a765e14#85 https://code.google.com/p/go/source/browse/src/pkg/runtime/t...
- vessenes 11y agoAnecdotally, it's very often not bad, (and in fact sometimes "good") to over-provision MAXPROCS. We have used as much as 3 to 6x the number of hyperthreaded cores with good results, depending on the workload. This could insulate you against some container changes.
- nulltype 11y agoSeems like if they did some other metric, it could overcount the number of CPUs instead, right? What about changing GOMAXPROCS once per minute in a goroutine that calls NumCPU()?