🍵 Green Tea GC: новый сборщик мусора в Go 1.25

- Источник
- Перевод

Свежая статья в официальном блоге разработчиков Go про экспериментальный сборщик мусора Green Tea, основанная на докладе Michael Knyszek с GopherCon 2025.

————

Go Team представили новый GC, который снижает время работы сборщика мусора на 10-40% в зависимости от нагрузки. Доступен в Go 1.25 через GOEXPERIMENT=greenteagc при сборке, уже используется в продакшене у Google, планируют сделать дефолтным в Go 1.26.

Как работает классический mark-sweep:

- Mark фаза: обходим граф объектов от корней (глобальные/локальные переменные), помечаем всё достижимое
- Sweep фаза: всё, что не посетили — мусор, освобождаем память
- По сути простой graph flood алгоритм, как обход графа в ширину/глубину

Суть проблемы:

- Около 90% времени GC тратится на marking, только 10% на sweep
- Из этих 90% минимум 35% уходит на простои при обращении к памяти
- Graph flood алгоритм прыгает по всей хипе, выполняя маленькие кусочки работы — CPU не может предсказать следующий шаг
- Плохо использует кэши: два объекта со ссылкой друг на друга могут быть где угодно в памяти
- CPU постоянно стопорится на обращениях к main memory (до 100x медленнее кэша)

Автор использует хорошую аналогию: если ехать на машине по городским улицам — постоянно тормозить на поворотах и светофорах, то большую скорость не набрать.

Что хуже — тренды железа играют против GC: NUMA-архитектуры, снижение memory bandwidth на ядро, всё больше ядер (конкуренция за shared queue), новые фичи типа векторных инструкций не используются.

🟢Решение Green Tea — гениально простое:

- Работать со страницами памяти, а не с отдельными объектами
- Вместо сканирования объектов — сканируем целые страницы
- Трекаем страницы в work list, а не объекты
- Метаданные о marked объектах хранятся локально для каждой страницы

Результат: делаем меньше, но более длинные проходы по памяти. Это как выехать из города на шоссе — наконец-то можно разогнаться.

Бонусом используют AVX-512 векторные инструкции для турбо-ускорения сканирования — держат всю метаданные страницы в двух 512-битных регистрах прямо на CPU, обрабатывают целую страницу за несколько инструкций. Это было невозможно для graph flood из-за непредсказуемости размеров объектов.

Правда, есть воркллоады, которые не выигрывают или даже регрессируют (когда на странице обычно только один объект для сканирования). Но таких меньшинство, и даже сканирование 2% страницы уже даёт профит над graph flood.

————

🟠Отличная статья, must read для всех.

Особенно радует, что они не просто предлагают "попробуйте новую фичу", а уже раскатили это внутри Google и просят фидбек. Production-ready, а не просто эксперимент.

P.S. Очень понравилась история происхождения названия — когда Austin делал прототип, он был в Японии и пил матчу литрами 🍵
Я через пару недель собираюсь делать то же самое 🇯🇵✨

#go1_25 #go_official #gc #performance

📉 Величие и нищета Prometheus метрик: альтернатива от VictoriaMetrics

https://habr.com/ru/articles/960654/

Автор столкнулся с классической проблемой: его сервис жрёт память, и оказалось, что почти 30 МБ из них уходят на... метрики. Точнее, на Summary метрики из prometheus/client_golang, которые вычисляют квантили на стороне приложения.

Решил попробовать альтернативу — библиотеку github.com/VictoriaMetrics/metrics.

Чем отличается:

У Виктории проще API:
- Нет разделения на векторы и скаляры
- Имя метрики и лейблы идут вместе в одной строке: metric_name{label1="value1",label2="value2"}
- Рекомендуется группировать метрики по Set'ам (удобно для организации)
- Не поддерживает HELP метадату (VictoriaMetrics её игнорирует)

Кастомные коллекторы:
- У Prometheus есть Collector интерфейс из коробки
- У Виктории придётся писать самому (запускать по таймеру, собирать статистику)
- Метрики нужно явно дерегистрировать при удалении

Результат:
- Экономия 25-30% памяти (квантили считаются через более легковесную библиотеку)
- Но выросла нагрузка на GC (из-за создания строк при каждом обновлении метрики)

————

Честно говоря, VictoriaMetrics как-то всегда проходила мимо меня, поэтому с интересом почитал статью. Неплохая альтернатива устоявшемуся решению. Виктория явно минималистичнее и проще, но за это придётся платить гибкостью — нет удобных коллекторов, нет нормальной поддержки хуков для всех типов метрик (а надо ли?).

В общем, если у вас много Summary метрик и память поджимает — стоит посмотреть. Для остальных случаев Prometheus вполне достаточен.

#article #metrics #prometheus #victoriametrics

Идём на Avito Infra DrinkUp 12 ноября, без вариантов ☄️

Коллеги из Авито зовут на встречу по инфраструктуре. Обещают брейншторм об инструментах IaC, разработке в SRE, базах данных, Kubernetes и многом другом. Но есть подвох: никаких записей и трансляций — только офлайн, только хард-кор.

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

#промо #текст_прислан

🗺 Как Swiss Tables в Go 1.24 сэкономили сотни гигабайт памяти

https://www.datadoghq.com/blog/engineering/go-swiss-tables/

Nayef Ghattas из Datadog рассказывает про неожиданный сюрприз после обновления на Go 1.24. Это продолжение их истории про memory regression, но с хорошим концом.

TL;DR: после обновления на Go 1.24, словили баг с утечкой памяти, но при этом в высоконагруженных средах потребление памяти внезапно СОКРАТИЛОСЬ на сотни мегабайт. Виновник — новая реализация map через Swiss Tables.

Суть проблемы:

В Datadog используют огромную мапу shardRoutingCache (3.5 миллиона элементов в высоконагруженных окружениях) для роутинга данных по шардам. После обновления на Go 1.24 эта мапа стала занимать ~500 MiB меньше в памяти.

Старая реализация (Go 1.23):

- Hash table с бакетами, по 8 слотов в каждом
- Load factor максимум 13/16 (81.25%)
- При росте мапы старые бакеты висят в памяти, пока не скопируются инкрементально
- Overflow buckets — цепочки дополнительных бакетов при переполнении основных

Итог: 726 MiB для 3.5M элементов

🟢Если хотите понимать, что всё это значит, вот подробный разбор старой реализации Map (до Swiss Map)

Новая реализация (Go 1.24) — Swiss Tables:

- Данные хранятся в группах по 8 слотов с control word (8 байт)
- Control word — это 8 байт метаданных, каждый байт хранит последние 7 бит хеша ключа
- SIMD-оптимизация: сравнение хеша со всеми 8 слотами за одну CPU-инструкцию
- Load factor теперь 7/8 (87.5%) — меньше пустого места
- Нет overflow buckets — просто идём в следующую группу
- Extendible hashing: мапа делится на независимые таблицы по 128 групп максимум

Итог: 217 MiB для тех же 3.5M элементов

Математика:

Go 1.23: ~1.5M бакетов × 464 байта = 726 MiB
Go 1.24: ~3900 таблиц × 58 KiB = 217 MiB
Экономия: ~509 MiB live heap (≈1 GiB RSS с учётом GOGC)

Бонусный раунд оптимизации:

Авторы заметили, что в структуре Response хранятся неиспользуемые поля: пустая строка RoutingKey и nil-указатель LastModified. Плюс ShardType был int (8 байт) для enum из 3 значений.

Что сделали:

- ShardType: int → uint8 (1 байт вместо 8)
- Создали отдельный тип cachedResponse без лишних полей
- Key-value пара: 56 байт → 24 байта

Результат: ещё 250 MiB RSS экономии на под, 200 TiB памяти сэкономили по всему флоту.

————

Отличная статья, показывающая насколько важны детали в Go. Swiss Tables — это не просто "новая реализация map", это значимая экономия ресурсов в проде.

Из забавного: в low-traffic окружениях экономия была всего ~28 MiB, что не покрыло регрессию из mallocgc. Зато в high-traffic всё окупилось с лихвой.

P.S. SIMD для map пока только на amd64, для arm64 работа в процессе. Но даже без SIMD Swiss Tables экономят память за счёт более высокого load factor и отсутствия переполнения бакетов.

#article #go1_24 #performance #memory #english