🧠 Планировщик Go (GMP): Как 100 000 горутин работают на 4 ядрах — 8 апреля 2026 г. в 19:11:24.637
🧠 Планировщик Go (GMP): Как 100 000 горутин работают на 4 ядрах Джуны часто думают, что горутины это магия. Написал go func(), и оно как-то само параллелится. Сеньоры знают, что под капотом работает безжалостная и гениальная машина Go Scheduler. Понимание того, как он работает, спасает от жестких просадок производительности в Kubernetes. Погнали в хардкор. ОС (Linux/Windows) ничего не знает про горутины. Она умеет работать только с потоками ОС (OS Threads). Но потоки ОС тяжелые: у них большой стек (1-8 МБ) и их очень дорого переключать (context switch). Если создать 100 000 потоков ОС, ваш сервер умрет. Поэтому создатели Go написали свой планировщик (уровня user-space), который работает по модели G-M-P. • G (Goroutine) - Сама горутина. Легкая (стек всего ~2 КБ), содержит код, который нужно выполнить. • M (Machine) - Поток операционной системы. Именно он выполняет инструкции на процессоре. • P (Processor) - Логический процессор / Контекст. У него есть локальная очередь (Local Run Queue) из горутин (G), которые ждут выполнения. Количество P строго ограничено и по умолчанию равно количеству ядер вашего процессора (переменная GOMAXPROCS). Как это работает в динамике? Поток ОС (M) берет логический процессор (P), достает из его очереди горутину (G) и начинает её выполнять. Если горутина делает сетевой запрос или засыпает (time.Sleep), поток M не блокируется! Он откладывает эту G в сторону, берет из очереди P следующую G и продолжает работу. Безотходное производство. А что если горутина сделала тяжелый системный вызов (CGO или чтение файла)? Тут поток M неизбежно блокируется на уровне ОС. В этот момент планировщик Go делает финт ушами: он отрывает логический процессор P от заблокированного M, создает (или берет из пула) новый поток ОС M_new, прикрепляет к нему этот P и продолжает выполнять оставшиеся в очереди горутины. Старый M остается спать вместе со своей системной горутиной. 🔥 Киллер-фича: Work Stealing (Кража работы) Представьте, что один P быстро выполнил все свои горутины, а у другого P в очереди их еще 100. Чтобы ядра не простаивали, свободный P пойдет к соседу и украдет у него ровно половину горутин из очереди. Коммунизм в чистом виде. ☝️ Senior Tip: Ловушка Kubernetes и CFS Quota Вот ради чего всё это писалось. Если вы деплоите Go-сервис в Docker/K8s и ставите ему лимит limits.cpu: "2", вы думаете, что приложению дадут 2 ядра. Но Go при старте смотрит не на лимиты контейнера, а на железо хост-машины! Если на ноде 64 ядра, Go создаст 64 P (логических процессора) и наплодит 64 потока ОС. Linux увидит, что контейнер с лимитом в 2 ядра пытается выполнить 64 потока, и начнет их жестко троттлить (душить). Ваш сервис начнет дико тормозить на ровном месте. Лечение: Всегда синхронизируйте GOMAXPROCS с лимитами контейнера. Лучший способ - добавить один импорт в main.go, который сделает это автоматически при старте: import _ "go.uber.org/automaxprocs" #golang #underhood #architecture #performance #devops 👉 @golang_lib