GC в production: наблюдаемость, безопасность, edge cases и управление флотом

Go-сервис начинает день с 1% GC CPU. Через 60 минут gctrace показывает 39% CPU на коллекторе. Время concurrent mark выросло с 1,3 мс до 361 мс. Сервис в GC death-spiral — и OOM наступит раньше, чем дежурный дочитает алерт.

Чтение gctrace: GC death-spiral в Go

GODEBUG=gctrace=1 записывает одну строку на каждый цикл GC:

gc N @Ts X%: Apre+Aconc+Apost ms clock, ... ms cpu, Bpre->Bduring->Bafter MB, goal MB, P

Ключевые поля:

• X% — доля CPU в GC с начала программы.
• Aconc ms — время фазы concurrent маркировки.
• Bpre->Bduring->Bafter — размер кучи до, во время и после цикла.
• goal MB — размер кучи, который pacer нацеливает.

Сигнатура death-spiral:

gc 1   @0.012s  1%: 0.011+1.3+0.018 ms ...  4->4->1 MB,  5 MB goal
gc 2   @0.045s  3%: 0.024+5.8+0.032 ms ...  5->8->4 MB,  7 MB goal
...
gc 487 @61.2s  38%: 0.45+340+1.2 ms  ... 1820->2890->1450 MB, 1900 MB goal
gc 488 @62.1s  39%: 0.41+352+1.1 ms  ... 1900->2980->1490 MB, 1990 MB goal

Concurrent mark растёт с 1,3 мс → 352 мс, GC% поднимается с 1% до 39%: pacer не успевает завершить каждый цикл до следующей волны аллокаций. Коллектор отстаёт; pacer отвечает более частым планированием GC, что крадёт CPU, снижает throughput приложения, что делает давление аллокаций хуже относительно доступного CPU. Без вмешательства — OOM.

Приоритет правок:

1. Немедленно — найти hotspot аллокаций через /debug/pprof/allocs; сократить rate аллокаций. Даже 50% сокращение должно опустить GC CPU ниже 15%.
2. Краткосрочно — установить GOMEMLIMIT в ~90% лимита контейнера; pacer будет защищать эту границу.
3. Настройка — GOGC=200 откладывает GC (куча удваивается-удваивается, меньше циклов). Только после сокращения аллокаций; маскирует, не лечит.
4. Архитектура — если workload реально нуждается в большом объёме живых данных, рассмотреть off-heap хранилища (Redis, mmap’d файлы) вместо in-heap кэшей.

Наблюдаемость в production по рантаймам

Паттерн senior-дашборда — четыре панели на сервис:

1. Rate аллокаций (байт/с) во времени.
2. Распределение пауз GC (гистограмма p50/p99/max).
3. Доля GC в CPU (%).
4. Тренд размера кучи vs live-set.

Привязать к сгоранию SLO: регрессии пауз GC — ведущий индикатор нарушений SLO по хвостовой latency. Алерты: rate аллокаций выше порога сервиса (300–500 МБ/с/ядро) более 5 минут; p99 пауза выше 100 мс (G1) / 5 мс (ZGC) / 50 мс (Go); GC CPU > 10%.

Безопасность: DoS через аллокации

Злоумышленник, способный заставить сервер аллоцировать большие объекты, может довести его до OOM или разрушительного давления GC. Heap exhaustion входит в OWASP Top 10 server-side DoS векторов.

Векторы атаки:

• Тела запросов без ограничений: парсинг 100 МБ JSON, чтобы обнаружить одно плохое поле.
• Неограниченные результаты запросов: вернуть все строки, когда ожидалась пагинация.
• Regex bombs: backtracking аллоцирует промежуточное состояние.
• Zip-bomb декомпрессия: маленький input → огромный output.
• Глубокая вложенность JSON: рекурсивные парсеры аллоцируют объекты, эквивалентные call stack.

Меры защиты:

• Ограничения размера тела запроса на шлюзе (1 МБ по умолчанию; больше на конкретных endpoint’ах с явной авторизацией).
• Ограничение размера результатов запросов на стороне сервера; никогда SELECT * без LIMIT.
• RE2-based regex (без backtracking; линейное время).
• Проверка коэффициентов сжатия до декомпрессии.
• Per-request memory tracking с жёсткими лимитами и явной обработкой переполнения.

Edge cases

Finalizer storms: регистрация многих объектов с finalizers’ами (Object.finalize в Java, runtime.SetFinalizer в Go, FinalizationRegistry в JS) требует, чтобы GC ставил их в очередь для отдельного finalizer-потока. Всплеск finalisable объектов в тесном цикле может застопорить коллектор, пока очередь finalizer’ов не опустеет. Файловые дескрипторы, сокеты и нативная память, удерживаемые finalizers’ами, остаются открытыми до обработки очереди.

Решение: полностью избегать finalizers’ов. Использовать явные close() / Closeable / defer. В Java java.lang.ref.Cleaner (JDK 9+) — более безопасный backstop, чем finalize(). В Go предпочитать defer вместо SetFinalizer.

Pinned objects: объекты, которые не могут быть перемещены (DMA-буферы, JNI-pinned массивы, типизированная внешняя память V8), мешают коллектору компактизировать кучу. Устойчивая утечка pinned объектов фрагментирует кучу и вызывает OOM при низкой утилизации.

Решение: явный lifecycle для pinning; аудит всего JNI/native interop. Алерты на метрики фрагментации кучи.

Ссылочные циклы с finalizers’ами: взаимные сильные ссылки между объектами, имеющими также finalizers’ы, могут предотвратить освобождение даже с cycle collector’ом, поскольку finalizers’ы должны выполняться в определённом порядке, который GC не всегда может определить. Решение: WeakRef там, где уместно; никогда не комбинировать finalizers’ы с циклическими сильными ссылками.

История: 1960 – 2024

Пять шагов за 64 года:

1. 1960 — Lisp Маккарти вводит mark-sweep. Первый программный GC, пакетный и медленный.
2. 1970 — копирующий коллектор Cheney. Делит кучу, копирует живое, bump-pointer аллокация. До сих пор влияет на Scavenger V8.
3. 1984 — поколенческая гипотеза Ангара (Berkeley Smalltalk). Большинство объектов умирают молодыми; используй это.
4. 1990-е — инкрементальные и concurrent GC (Baker, Yuasa, абстрактный фреймворк Dijkstra). Паузы падают с секунд до десятков мс.
5. 2010-е–2020-е — low-pause concurrent коллекторы (G1, ZGC, Shenandoah, tri-color Go, V8 Orinoco). Субмиллисекундные паузы на кучах несколько ГБ. Замкнутые pacers, generational ZGC, энергоэффективная настройка для облачных workloads.

Каждое поколение снижало стоимость пауз на порядок.

Production-истории

Discord 2020: хвостовая latency chat-сервиса определялась паузами GC. Переход на улучшенный pacer Go 1.14 снизил p99 на 40%.

LinkedIn 2018: мигрировали большой Kafka-кластер с CMS на G1. p99 latency упала на 25-50%, нагрузка на операторов снизилась.

Netflix 2022: развернули ZGC на Cassandra-флоте. p99 read latency улучшилась в 5-10x без изменений в коде приложения.

Twitter 2019: finalizer storm вызвал OOM в JVM-сервисе. Заменили явными Closeable.

Stripe 2023: Go-сервис впервые достиг GOMEMLIMIT во время пика трафика. Pacer удержал память в пределах, но throughput упал на 15% — диагностировано и исправлено сокращением аллокаций на hot path.

Паттерн: у каждого крупного production-сервиса есть своя GC-история. Senior инженеры исходят из предположения, что GC будет вопросом; цель — знать, когда это ответ.