Настройка GC: пейсинг, форма кучи и наблюдаемость аллокаций

Go-сервис запущен в контейнере с лимитом 4 ГБ. GOGC оставлен по умолчанию 100. При нагрузке куча вырастает до 3,8 ГБ, pаcer запускает интенсивные циклы GC, и под падает от OOM. Добавление GOMEMLIMIT=3600MiB решает проблему — без изменения кода и без смены коллектора.

Пейсинг и мягкий лимит памяти

Современные коллекторы управляют собой сами: предсказывают, когда нужно запустить следующий цикл, чтобы успеть завершить его до исчерпания кучи. Go’s pacer (переработан в 1.18, доработан в 1.19 с GOMEMLIMIT) смешивает два сигнала — rate роста кучи и долю CPU в GC — в замкнутый контроллер. Цель G1 по времени паузы направляет его pacer к удержанию пауз ниже заданного.

Knobs Go:

• GOGC=100 (по умолчанию) — запускать GC, когда живые байты удвоились с последнего цикла. Увеличить — откладывать GC (больше памяти, реже циклы); уменьшить — цикличнее (меньше памяти, больше CPU).
• GOMEMLIMIT — мягкий лимит на общую память рантайма. Pacer становится агрессивнее по мере приближения к лимиту, принимая меньший throughput ради соблюдения границы. Для контейнеризованных сервисов устанавливать в ~90% лимита контейнера.

Knobs JVM:

• -Xmx — жёсткий потолок кучи.
• -XX:MaxGCPauseMillis=N — G1 нацеливается на паузы N мс, регулируя размеры регионов и частоту сборки. Слишком малое значение → G1 пересобирает, теряя throughput. Слишком большое → изредка видим 200 мс спайк.

Форма кучи и live-set

Общая куча (RSS) — не то же самое, что live-set — байты, которые реально достижимы. RSS 4 ГБ может содержать лишь 800 МБ живых данных; оставшиеся 3,2 ГБ — мусор, ожидающий следующего цикла, или фрагментация, или зарезервированные арены рантайма.

Время маркировки пропорционально живым байтам, а не RSS. Частота циклов пропорциональна rate аллокаций. Канонический ориентир: размер кучи ~1,5–2x live-set — меньше и GC работает почти непрерывно; больше и память тратится впустую без пропорционального выигрыша в latency.

Workloads с большим изменчивым live-set (in-memory кэши, большие агрегации) нуждаются в верхней части диапазона. Маленькие стабильные сервисы работают экономно при 1,5x.

Наблюдаемость аллокаций по рантаймам

Без инструментации рантайма диагноз ставится вслепую.

Go: пакет runtime/metrics + скрейп /debug/pprof/allocs каждые 30 с. GODEBUG=gctrace=1 — каждый цикл в stderr (полезно при разработке, шумно в prod).

JVM: -Xlog:gc*:file=gc.log:time,uptime,level,tags для ротируемых GC-логов. JFR ObjectAllocationInNewTLAB для профилирования аллокаций. Micrometer экспортирует гистограмму gc_pause_seconds и rate gc_memory_allocated_bytes_total в Prometheus.

V8 / Node: process.memoryUsage().heapUsed каждые 15 с; v8.getHeapStatistics() для детального view. perf_hooks.PerformanceObserver с типом 'gc' перехватывает каждое событие паузы программно.

.NET: rate GC.GetTotalAllocatedBytes() + dotnet-counters monitor для live просмотра gen-0-gc-count, gen-1-gc-count, gen-2-gc-count и alloc-rate.

Кросс-рантаймовый паттерн алерта: rate аллокаций выше порога сервиса (обычно 300–500 МБ/с/ядро) более 5 минут. Пара rate аллокаций с p99 на одном графике — когда расходятся, подозревают GC.

Object pooling: когда работает, когда нет

Пулинг переиспользует аллокации для снижения давления GC. Хорошо работает для объектов, дорогих в создании и кратко используемых на hot path: bytes.Buffer, JSON-энкодеры, regexp-объекты, scratch slices.

Пулинг вредит:

• Объекты дёшевы в создании (накладные расходы пула превышают экономию).
• Объекты долгоживущие (пул держит память без освобождения).
• Координационные расходы потоков превышают стоимость аллокации.

У sync.Pool Go есть преимущество: GC может опустошить пул между циклами, память не заблокирована навсегда. Пулы JVM и .NET держат память до явного освобождения — следите за max-pool-size.

Правило: пулить только то, что профиль отмечает как горячий узел аллокации. Не пулить превентивно.