Практика syscall-нагрузки

Семафор ограничивает параллелизм

Если каждая из тысяч горутин уходит в блокирующий syscall, потоков не хватает (урок). Решение — ограничить, сколько горутин одновременно могут быть «в syscall»: перед вызовом горутина занимает одно из N разрешений, а после — освобождает. Простейший семафор — буферизованный канал:

sem := make(chan struct{}, N) // N разрешений
sem <- struct{}{}             // занять: при занятых N — блокировка
<-sem                         // освободить

Подробнее такой семафор разобран в уроке; здесь важна сама идея: блокирующий I/O — дефицитный ресурс, его лимитируют явно. Именно этот скелет Миша и поставил на экспорт архивов.

GOMAXPROCS — под квоту CPU

Второй рычаг — GOMAXPROCS, но работает он не так, как иногда советуют. Поток, заблокированный в syscall, не занимает P и не учитывается в лимите GOMAXPROCS: P перехватывает другой M, а новые потоки runtime заводит сам, по потребности — их может быть больше числа P (предел в runtime велик, урок). Поэтому поднимать GOMAXPROCS выше числа ядер «ради застрявших потоков» не нужно: это не добавляет запасных потоков, а лишь добавляет конкуренцию за ядра и лишние переключения. GOMAXPROCS подбирают под фактическую квоту CPU — в контейнере под её лимит — и проверяют измерениями; универсального рецепта нет. Ровно так Миша и разобрал настройку Димы: тот лечил несуществующую проблему.

Что важно понять

Сетевой I/O не нужно лимитировать ради спасения потоков — poller; семафоры для сети ставят ради пулов соединений и защиты бэкенда. Дисковый — нужно: это редкий и дорогой ресурс. Знание механики из превращается в инженерные решения: где ставить семафор, как настроить GOMAXPROCS, сколько воркеров в пуле.