а не пул

иначе (в случае, например, ддос) у тебя сервис умрет на одном типе горутин, не пропуская другие.

если там есть любое io то разницы нет в чем)

а вот ддос надо не на воркер пулах останавливать!

вот оно - ищем под фонарем, а не там, где потеряли

man cgroups :)

docker?)

ддос от других сервисов

google oom kill

docker run --restart ...

Вот только есть одна особенность, рантайм ничего не знает про ограничение cpu через cgroups, из-за чего спавнит потоки по числу реальных ядер. Uber даже написали либу, которая подкручивает gomaxprocs по значению из cgroup

коллеги, астанавитес

если вы мусорный трафик пропускаете на воркер-пулы - вы алени, и вам надо поехать в отпуск

почему это не надо? очень даже надо.

эту тему я обсуждать отказываюсь

фундаментальное недопонимание управления доступными ресурсами внутри приложения :) лимитированное создание горутин на буферизованном канале не будет отличаться от пула воркеров, если при заполненности канала не создавать горутину. если же создавать, то она со всеми своими потрахами (выделенной памятью под стэк 8кб и параметры) ляжет в очередь планировщика. если драйвер этого события будет работать чаще, чем успевает обработаться очередь в канале, то утилизация ресурсов будет бесконтрольно расти вне зависимости от убеждений, что в этом ничего страшного. oom kill ловится на ура, а на 1000 таких сгенеренных горутин с трудом просачиваются другие, которые по бизнес логике могут быть более полезными и должны иметь более высокую доступность.

как получить тип интерфейса, кто нить шурупит?

.(type)

не вышло
https://play.golang.org/p/vvH1xRvEWD0

я, коллега, напомню: у вас DOS, и вы его пропустили до приложения. на этом месте я бы рекоммендовал вам сервера просто выключить - эффект тот же, а для планеты полезнее.

Что нужно сделать чтобы при отправке http запроса на несуществующий домен не вылетала паника?