Комментарии 11
Но то, что нас убило, это переключение контекста процессора.
Нас убил недостаток физической памяти (а не виртуальной). Создание и исполнение каждого потока так или иначе требует какое-то количество физ памяти, которое ядро должно выделить. Если это, например, 100кб, то 180 000 x 100kb = 18 Gb физ памяти. Ядро ушло в свап
Там более дикое число:
По умолчанию каждый поток создаётся с мегабайтом адресного пространства.
Сижу перед своим виртуальным хвостом на неназванном провайдере. Смотрю на 700 гигов оперативки и 32 процессора. Думаю, что будет, если попробовать эту форк-бомбу. Но мысль о грядущем биллинге удручает.
Это перевод, копипаста или авторский текст? Я вижу качественный материал, но подпись "маркетолог" у автора меня смущает.
Хорошо бы во второй части увидеть больше про go и сравнение его реализации с тем, что есть в Java и .NET, в каждой из них есть реализация work stealing queue.
Что касается сервера и много потоков, то все не так однозначно. Поток, который ждёт IO, обрабатывается специальным образом и не тратит (тратит меньше) ресурсы CPU.
Я очень долго думал, как правильно перевести термин Work Stealing и остановился на Захвате Работы
Обычно переводят как "заимствование", например https://mylinuxprog.blogspot.com/2015/10/go.html
Не надо самому придумывать перевод, иногда достаточно почитать работы на похожие темы.
Мне очень нравится ваш стиль изложения.
Лезем в сорцы компилятора — как работает goscheduler (Часть I)