Настройка GOMAXPROCS для контейнерных сред (Kubernetes, Docker и др.)

⚠️ (Внимание: длинный и скучный материал)

Что такое GOMAXPROCS?

По умолчанию Go может запускать до 10 000 потоков одновременно, но фактическое количество потоков, выполняющихся параллельно, определяется важным параметром — GOMAXPROCS.

GOMAXPROCS устанавливает ограничение на количество потоков ОС, которые могут одновременно исполнять пользовательский Go-код (не просто конкуррентно, а именно параллельно).

Значение по умолчанию соответствует количеству логических ядер CPU, которое видит ОС (runtime.NumCPU()).

Например, на моем MacOS это 8 ядер, а значит, Go будет одновременно выполнять до 8 потоков.

Запуск Go в контейнерах (Docker и Kubernetes)

В контейнеризированных средах, таких как Kubernetes, можно задать ограничения по CPU для каждого контейнера. Это означает, что контейнеру разрешено использовать только определённое количество процессорных ресурсов.

Пример:
🔹limit: 250m = 1/4 ядра
🔹limit: 1 = 1 полное ядро

Но проблема в том, что Go не видит эти ограничения. Он по-прежнему определяет количество доступных CPU на уровне хост-машины, а не контейнера.

(Хост-машина или нода может содержать несколько подов.)

Из-за этого Go-приложение может пытаться использовать больше процессорных ресурсов, чем ему выделено.

❓ "Но почему? Ведь чем больше CPU, тем лучше!"

Вот несколько причин, почему это может быть проблемой:

— Контекстные переключения – если потоков больше, чем ядер, ОС вынуждена чаще переключаться между ними.
— Неэффективное планирование – планировщик Go создаёт больше готовых к выполнению горутин, чем CPU может реально обработать, что приводит к избыточной конкуренции за процессорное время.
— Неэффективное выполнение CPU-bound задач – Go-программы часто CPU-bound, а значит, лучше работают, когда каждое ядро загружено ровно одним потоком без необходимости ожидания.

Если GOMAXPROCS больше, чем реально выделенные CPU-ресурсы, Go-рантайм планирует больше потоков, чем есть доступных ядер, что приводит к неэффективному выполнению.

✅ Решение

Если хочется автоматизировать настройку, можно использовать uber-go/automaxprocs. Эта библиотека корректирует GOMAXPROCS в соответствии с ограничением CPU контейнера.

(Если интересно, как работает uber-go/automaxprocs под капотом — просто скажите.)

Если вы понимаете спецификацию деплоя/пода, можно вручную задать переменную окружения GOMAXPROCS в соответствии с лимитом.

Но с точки зрения DevOps лучше вовсе избегать CPU-лимитов, а вместо них устанавливать только CPU requests (об этом подробнее ниже). Это касается не только Go-сервисов.

Задумайтесь об этом, если в вашем контейнере не задан лимит CPU.

Полезные ссылки:
— Почему не стоит использовать CPU-лимиты в Kubernetes
— Kubernetes CPU Limits и Go

👉 @juniorGolang | #tip

Оптимизируйте множественные вызовы с помощью singleflight

Допустим, у вас есть функция, которая получает данные по сети или выполняет ввод-вывод, и её выполнение занимает около 3 секунд:

Эта функция выдаёт новое значение каждые 10 секунд.

🔹Если вызвать эту функцию 3 раза подряд, общее время ожидания составит примерно 9 секунд.
🔹Если использовать 3 горутины, общее время ожидания может сократиться до 3 секунд, но функция всё равно будет вызвана 3 раза для получения одного и того же результата (~99%).

Здесь на помощь приходит пакет singleflight, который доступен по ссылке:
👉 golang.org/x/sync/singleflight.

Этот пакет позволяет выполнить функцию только один раз, независимо от того, сколько раз она была вызвана за эти 3 секунды, и возвращает один общий результат.

Это отлично подходит для оптимизации функций, работающих долго или потребляющих много ресурсов.

Как это работает?
1️⃣ Создаём объект singleflight.Group
2️⃣ Передаём в метод group.Do() функцию, которая выполняет дорогостоящие вычисления.

Метод group.Do() возвращает:

(result any, err error, shared bool)

Параметр shared показывает, был ли результат разделён между несколькими вызовами.

Зачем нужен аргумент key?
Ключ (key) — это идентификатор запроса.
Если поступает несколько запросов с одним и тем же ключом, singleflight понимает, что они запрашивают одно и то же.

Пример работы: Go Playground

С этим подходом, если функция вызывается несколько раз одновременно, фактически выполняется только один её вызов. А результат этого единственного вызова разделяется между всеми ожидающими

👉 @juniorGolang | #tip

Фильтрация без лишних аллокаций

При фильтрации слайсов в Go стандартный подход — создание нового слайса для отфильтрованных элементов.

Однако такой метод приводит к дополнительным аллокациям памяти.

Более эффективный способ — фильтровать «на месте», используя исходный массив слайса.

Как это работает:
• filtered := numbers[:0] создаёт новый слайс filtered, который ссылается на тот же массив, что и numbers, но имеет нулевую длину, сохраняя емкость numbers.
• Добавляя num в filtered, мы избегаем лишних аллокаций, так как просто изменяем содержимое numbers (или его базового массива).

Таким образом, мы не выделяем новую память, а заполняем уже существующий массив.

Этот метод особенно полезен, когда:
• numbers больше не нужен после фильтрации.
• Критична производительность, особенно при работе с большими объемами данных.

👉 @juniorGolang | #tip

Продолжайте работу с контекстами с помощью context.WithoutCancel()

Мы уже знаем, что при отмене родительского контекста отменяются и все его дочерние контексты, верно?
Но иногда это поведение нежелательно.

Есть случаи, когда нужно, чтобы определённые операции продолжались, даже если родительский контекст был отменён.

Представьте, что вы обрабатываете HTTP-запрос, и при его отмене (например, из-за таймаута или разрыва соединения с клиентом) всё ещё необходимо залогировать информацию о запросе и собрать метрики.

«Ха, просто создам новый контекст для этих операций»

Это возможно, но новый контекст не содержит значений из исходного контекста события, которые важны, например, для логирования или сбора метрик.

Передача значений возможна только через дочерний контекст.
Возвращаясь к примеру с HTTP-запросом, решение следующее:

context.WithoutCancel позволяет создать дочерний контекст, который не будет отменён при отмене родительского. Это обеспечивает завершение нужных операций даже после отмены запроса.

Кстати, эта функция появилась в Go 1.21. ✌️

👉 @juniorGolang | #tip

Избегайте использования math/rand, вместо этого используйте crypto/rand для генерации ключей

Когда вы работаете над проектами, где нужно генерировать ключи — например, для шифрования или создания уникальных идентификаторов — качество и безопасность этих ключей имеют большое значение.

Почему не math/rand?

Пакет math/rand генерирует псевдослучайные числа.

Это означает, что если известен способ генерации чисел (seed), можно предсказать их значения.
Даже если использовать в качестве seed текущее время (например, time.Now().UnixNano()), уровень непредсказуемости (энтропии) остаётся низким, потому что время между запусками не сильно отличается.

Почему crypto/rand?

Пакет crypto/rand предоставляет способ генерации криптографически стойких случайных чисел.

Он спроектирован таким образом, чтобы быть непредсказуемым, используя источники случайности от операционной системы, которые гораздо сложнее предугадать.
crypto/rand подходит для шифрования, аутентификации и других операций, чувствительных к безопасности.

👉 @juniorGolang | #tip