🐳 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 — довольно дешёвый способ найти старую настройку, которая больше не нужна.

🔗 Источник

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

#GoDeep