Мы все знаем, что runtime.GOMAXPROCS
по умолчанию установлено число ядер ЦП, что, если это свойство было установлено слишком большим?
GOMAXPROCS
по умолчанию установлено количество доступных логических ЦП по той причине, что в большинстве случаев это дает наилучшую производительность.
GOMAXPROCS
ограничивает только количество «активных» потоков, если горутина потока блокируется (например, системным вызовом), может быть запущен новый поток. Прямой корреляции нет, см. Количество потоков, используемых средой выполнения Go.
Если GOMAXPROCS
больше, чем количество доступных ЦП, то активных потоков будет больше, чем ядер ЦП, а это означает, что активные потоки должны быть «мультиплексированы» с доступными процессорами, поэтому да, будет больше переключателей контекста если есть больше активных потоков, чем ядер, что не всегда так.
Сборка мусора напрямую не связана с количеством потоков, так что об этом можно не беспокоиться. Цитата из пакета runtime
:
The GOGC variable sets the initial garbage collection target percentage. A collection is triggered when the ratio of freshly allocated data to live data remaining after the previous collection reaches this percentage. The default is GOGC=100. Setting GOGC=off disables the garbage collector entirely. The runtime/debug package's SetGCPercent function allows changing this percentage at run time. See https://golang.org/pkg/runtime/debug/#SetGCPercent.
Если у вас есть больше потоков, которые не выделяют/не освобождают память, это не должно влиять на то, как часто запускаются коллекции.
Могут быть случаи, когда установка GOMAXPROCS
выше количества процессоров увеличивает производительность вашего приложения, но они редки. Измерьте, чтобы узнать, поможет ли это в вашем случае.
Все это зависит от того, что делает ваш код, а не только от значения GOMAXPROC.