Go 1.26: Green Tea GC включили по умолчанию — у кого какие цифры после апгрейда?

[kube88]

Обновили основной API-сервис с 1.25 на 1.26. Главная обновка — Green Tea GC теперь работает по умолчанию (в 1.25 прятался за GOEXPERIMENT=greenteagc, руки так и не дошли попробовать).

Сервис на 16 ядрах, ~3k RPS, много мелких аллокаций на каждый запрос. Метрики за неделю против прошлой: затраты CPU на GC 4.1% → 2.7%, p99 ответа 19 мс → 16 мс. Код не трогали вообще — буквально бесплатные три миллисекунды за смену цифры в Dockerfile.

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

[rignoz1]

У нас как раз такой кейс: ETL-пайплайн, ~2 млн аллокаций в секунду, тонны мелких структур. Гоняли честный A/B неделю: две идентичные ноды, одна на 1.25 со старым GC, вторая на 1.26.

По GODEBUG=gctrace=1: время маркировки минус 38%, общий троупут пайплайна +9-11% в зависимости от типа задач. Паузы как были суб-миллисекундными, так и остались — важно понимать, что Green Tea не про паузы, а про стоимость всего цикла: сканирование идёт по спанам, а не по отдельным объектам вразброс, отсюда локальность кэша и выигрыш именно на куче мелочи. На больших долгоживущих буферах разницы почти нет.

Практические заметки. Откат, если что-то пошло не так: GOEXPERIMENT=nogreenteagc, пересборка не нужна никакая магия — просто env при сборке. Меряйте через benchstat с десятком прогонов минимум, разницу в 5-7% на глаз вы не увидите, а самовнушение работает в обе стороны. И отдельно: с 1.25 GOMAXPROCS контейнер-аварный — если у вас в проде костыль automaxprocs, его пора сносить, у нас он конфликтовал с新ым поведением при изменении лимитов на лету. Пардон, с новым поведением — клавиатура.

[postgres_andy]

Дежурный комментарий зануды. Если у вас CRUD на 200 RPS и ORM на рефлексии, то GC у вас болит в последнюю очередь. Снимите pprof, прежде чем радоваться чужим бенчмаркам: у половины сервисов, которые я смотрел за последний год, треть CPU уходит в сериализацию JSON и работу со строками, а сборщик где-то на пятом месте. Апгрейд — это хорошо, но он не заменяет профилирование.

[Omoto]

Кстати, про JSON — раз уж зашло. Пробуйте encoding/json/v2 за флагом GOEXPERIMENT=jsonv2: на наших профилях декод ускорился в 2.3 раза, маршалинг — в 1.6. Но совместимость не стопроцентная, гоняйте тесты: у нас всплыло отличие в обработке time.Time и поведении omitempty на пустых слайсах. Вместе с новым GC получается приличный прирост вообще без переписывания кода.

[jodgould]

А кто-нибудь сравнивал в k8s с жёсткими лимитами? У нас поды по 2 CPU в Яндекс Облаке, и после переезда на 1.26 троттлинга в метриках заметно меньше. Но мы прыгали сразу с 1.24, так что не могу понять, что сработало — новый GC или контейнер-аварный GOMAXPROCS, который приехал заодно из 1.25.

[radiomaker]

Если прыгали с 1.24 — почти наверняка GOMAXPROCS. Раньше рантайм видел все 64 ядра ноды, плодил процессоры под них, и планировщик упирался в CFS-квоту — отсюда троттлинг. Теперь рантайм сам читает лимиты cgroups. Green Tea сверху добавил, но основной эффект у вас от этого. И поставьте заодно GOMEMLIMIT, если под зажат по памяти — классическая связка, спасает от OOM-киллера на пиках.