Go в Kubernetes мог зря конкурировать за CPU — с Go 1.25 это… — Библиотека Go-разработчика

Библиотека Go-разработчика | Golang@goproglib · 24.1K subscribers Open in TelegramOpen

Go в Kubernetes мог зря конкурировать за CPU — с Go 1.25 это изменилось

До Go 1.25 рантайм ориентировался на CPU всей машины. Поэтому pod с лимитом в 2 CPU на 64-ядерной ноде мог получить GOMAXPROCS=64.

Linux при превышении CPU limit начинал throttling — процесс мог полностью приостанавливаться на оставшуюся часть периода. Это особенно неприятно для tail latency.

В Go 1.25 рантайм на Linux начал учитывать CPU limit из cgroup:

runtime.GOMAXPROCS(0)

Например, pod с лимитом в 2 CPU → GOMAXPROCS будет 2. Значение также периодически пересчитывается, если cgroup limit меняется.

⚠️ Но есть ловушка: если вы вручную задаёте GOMAXPROCS через env или:


runtime.GOMAXPROCS(8)

автоматическая настройка отключается.

То же самое касается старого automaxprocs: после перехода на Go 1.25+ стоит проверить, нужен ли он вообще. И ещё нюанс: Go ориентируется на CPU limit, а не CPU request.

Если Go-сервис живёт в Kubernetes, проверить GOMAXPROCS после обновления Go — довольно дешёвый способ найти старую настройку, которая больше не нужна.