Go 1.26 и Green Tea GC по умолчанию: собрал цифры с прода за неделю, делитесь своими

[davidwor]

Обновили основной API-сервис с Go 1.25 на 1.26 — тот самый релиз, где сборщик Green Tea стал дефолтом (в 1.25 он жил за GOEXPERIMENT=greenteagc, и многие, судя по чатам, так его и не включали).

Сервис: gRPC плюс HTTP-гейтвей, ~9k RPS в пике, куча мелких аллокаций (протобуфы, мапы, строки), heap около 6 ГБ, GOGC=100, GOMEMLIMIT=10GiB, k8s, лимит 8 CPU на под.

Неделя наблюдений, сравнение по графикам за равные периоды:
— доля CPU на GC: было ~7.1%, стало ~4.4%
— p99 ответа: 41 мс → 34 мс
— p50 почти не сдвинулся: 3.9 → 3.8 мс
— пропускная при том же CPU-бюджете +6–7%

Кода не меняли вообще, только версию в Dockerfile. Откат на старый сборщик, если что, простой:

Код: Выделить всё

GOEXPERIMENT=nogreenteagc go build ./...

Кто ещё переехал? Особенно интересны цифры на жирных хипах от 30 ГБ и на ARM-нодах.

[coder_vlad]

А у нас тишина. CLI-утилиты и пара воркеров с хипом по 200–300 МБ — разницы ноль, всё в пределах шума. Что, в общем-то, логично: на маленьком хипе GC и раньше стоил копейки, экономить нечего. Так что если у вас не сервисы с гигабайтами живых объектов — не ждите чуда, просто спокойно обновляйтесь ради остального.

[debian91]

@davidwor, Поясню, почему оно быстрее и кому именно, а то «новый GC» звучит как магия.

Старый сборщик сканировал объекты поодиночке в порядке обхода графа. По памяти это случайные прыжки: кэш процессора постоянно промахивается, ядра простаивают в ожидании RAM. Green Tea группирует работу по спанам — блокам по 8 КБ: вместо «объект за объектом» сканируется пачкой всё отмеченное внутри спана. Меньше кэш-промахов, лучше масштабирование по ядрам, и именно поэтому в анонсах фигурировал разброс 10–40% экономии GC-времени.

Отсюда профиль выгодополучателя: много мелких долгоживущих объектов (графы, кэши, десериализованные протобуфы), многоядерные машины, заметная доля CPU на GC до апгрейда. У ТС ровно такой случай. На коде, где всё живёт на стеке или умирает молодым, эффект около нуля — что и подтверждает сосед выше.

Любопытная деталь: на наших ARM-нодах относительный выигрыш вышел больше, чем на x86 — видимо, сказывается соотношение скорости ядер и памяти. И отдельно отмечу: паузы как были субмиллисекундными, так и остались, тут ничего не поменялось, выигрыш именно в фоновой работе маркировки.

[Vthors22]

Цифры с жирного, раз просили: in-memory поисковый индекс, heap 48 ГБ, машина на 64 ядра. Паузы и раньше не болели, но под пиковой записью душил ассист-троттлинг — горутины-аллокаторы принудительно помогали сборщику. После 1.26: время в mark-фазе минус ~35%, хвост p99.9 на индексации упал с 280 мс до 190. Для нас это самый полезный релиз со времён 1.21, даже обсуждать нечего.

[k8s_master]

Добавлю занудства: прежде чем мерить новый GC, проверьте базу. Удивительное рядом, но половина знакомых сервисов до сих пор живёт с дефолтным GOGC без GOMEMLIMIT и с лишними аллокациями в горячем пути, которые видны в первом же profile за 5 минут. Правильно выставленный GOMEMLIMIT плюс sync.Pool в паре мест у нас дали больше, чем любая смена сборщика. Сначала это, потом уже бенчмарки релизов.