Необходимо ли ограничивать количество подпрограмм go при полностью связанной с процессором рабочей нагрузке?

# #go #goroutine

Вопрос:

Если да, то как определить этот максимум? Это самая важная часть для меня. Я бы очень хотел, чтобы он был установлен вручную. Я подумал об использовании runtime.GOMAXPROCS(0) , так как сомневаюсь, что больший параллелизм принесет какие-либо дополнительные преимущества. Комментарий, по-видимому, предполагает, что в какой-то момент он помечен как устаревший.

Из того, что я понял, единственным ограничивающим фактором, когда речь заходит о процедурах go, является память, поскольку для спящей процедуры go все еще требуется память для ее стека.

Ответ №1:

В этом нет особой необходимости. Количество потоков, выполняющих эти программы, по умолчанию равно количеству ядер процессора на компьютере (настраивается через GOMAXPROCS ), поэтому на уровне потоков не будет разногласий.

Однако вы можете получить преимущества в производительности за счет меньшего количества готовых к запуску гороутов из-за эффектов кэширования памяти. Например, на 8-ядерном компьютере, если у вас есть 1000 активных подпрограмм, которые все касаются значительных объемов памяти, к тому времени, когда подпрограмма снова запустится, необходимые страницы памяти, вероятно, уже будут удалены из кэша вашего процессора. С меньшим количеством гороутов шансы на попадание в кэш выше.

Как всегда в вопросах производительности: единственный способ быть уверенным — это измерить его самостоятельно с помощью репрезентативной рабочей нагрузки.

Ответ №2:

В ходе нашего тестирования мы определили, что лучше всего создавать фиксированное количество рабочих процедур и использовать их для выполнения всей работы. Создание и уничтожение goroutines является легким, но не полностью свободным от накладных расходов. Эти накладные расходы обычно незначительны, если гороутины проводят какое-либо количество заблокированного времени.

Ответ №3:

горутины очень легкие, поэтому это полностью зависит от системы, в которой вы работаете. У среднестатистического процесса не должно возникнуть проблем с менее чем миллионом одновременных процедур в 4 ГБ оперативной памяти. Подходит ли это для вашей целевой платформы-это, конечно, то, на что мы не можем ответить, не зная, что это за платформа.

смотрите эту статью и это, они полезны