Представьте сервис с десятками тысяч горутин: стек каждой вырос, но объём heap почти прежний. Что именно в работе GC может увеличить затраты на маркировку?
Большие стеки горутин увеличивают объём корней, который сборщик мусора должен просканировать. Поэтому затраты на маркировку могут вырасти даже при неизменном размере heap: GC проверяет указательные слоты стеков и добавляет найденные объекты в граф достижимости.
Это не означает, что вся работа обязательно превращается в длинную STW-паузу. Сканирование стеков в основном выполняется в рамках конкурентной маркировки, но оно увеличивает общий объём работы GC, может влиять на начальную фазу и повышать задержки при завершении цикла.
Конкурентный сборщик мусора Go создавался для автоматического управления памятью с небольшими остановками приложения. Для этого значительная часть маркировки выполняется параллельно с пользовательскими горутинами, однако GC всё равно должен начать с поиска всех корней: глобальных переменных, стеков и других runtime-структур.
Такой подход уменьшает зависимость пауз от всего размера heap, но не устраняет зависимость от количества и размера корней. Стек горутины является частью этого набора корней, даже если большая часть объектов, на которые он ссылается, впоследствии окажется недостижимой.
Большое число горутин часто воспринимают как проблему только планировщика или потребления памяти стеков. На практике выросшие стеки создают дополнительную работу для каждого цикла GC: runtime должен просмотреть их содержимое и определить, какие слова могут быть указателями на живые объекты.
Неверный вывод — считать, что неизменный объём heap гарантирует неизменное время GC. При большом количестве горутин можно получить рост CPU-нагрузки сборщика, увеличение задержек и конкуренцию за процессор даже без заметного роста живой памяти.
Во время маркировки GC строит множество достижимых объектов. Сначала он обрабатывает корни, среди которых находятся стеки горутин. Для каждого стека runtime использует информацию компилятора о расположении указателей и сканирует соответствующие области, находя ссылки на объекты heap.
Стоимость зависит не только от числа горутин, но и от суммарного размера их стеков, количества указательных слотов и фактического числа обнаруженных ссылок. Большой стек с большим количеством неиспользуемого пространства тоже может требовать сканирования, хотя он не увеличивает число живых объектов в heap.
Сканирование стеков не равно последовательному сканированию всего heap. Неподвижные данные без указателей не требуют обхода графа объектов, а для стеков runtime располагает картами указателей. Тем не менее проверка корней и обработка найденных ссылок остаются обязательной работой.
Рост стеков может быть связан с глубокой рекурсией, длинными цепочками вызовов, крупными локальными значениями или временным пиком нагрузки. После уменьшения глубины вызовов стек не обязательно немедленно возвращается операционной системе: runtime может сохранить выделенную ёмкость для последующего использования. Поэтому кратковременный пик числа горутин способен дольше влиять на стоимость GC.
Важно различать объём стека и число живых объектов. Первый влияет на объём сканируемых корней, второй — на дальнейший обход графа heap. Оптимизация только heap-аллокаций не устранит проблему, если основная стоимость вызвана большим числом одновременно активных горутин или их глубокими стеками.
На практике проверяют профиль CPU и метрики GC, сопоставляя их с числом горутин, их состояниями и характером нагрузки. Уменьшать число горутин следует не автоматически: это может ухудшить пропускную способность. Обычно ищут избыточную конкурентность, зависшие задачи и чрезмерную глубину вызовов, после чего проверяют эффект измерениями.
В сервисе обработки сообщений число горутин выросло с нескольких тысяч до десятков тысяч из-за создания отдельной горутины для каждого ожидающего результата. Размер живого heap почти не изменился, но CPU-время GC и задержки на пике нагрузки увеличились. Профилирование показало множество горутин с длинными стеками ожидания и вызовами через несколько уровней обёрток.
Рассматривались три варианта. Увеличение GOGC могло сократить частоту циклов, но повысило бы допустимый объём памяти и не устранило стоимость сканирования больших стеков. Принудительный вызов GC был отвергнут, поскольку он добавил бы лишние циклы и ухудшил задержки. Уменьшение размера локальных структур помогло бы частично, но не решало проблему избыточного числа горутин.
Выбрали ограниченный пул рабочих горутин и передачу сообщений через очереди. Это уменьшило число одновременно существующих стеков и сделало их глубину более предсказуемой. В результате снизились затраты GC и хвостовые задержки, хотя пришлось аккуратно настроить размер пула, чтобы не создать очередь ожидания и не потерять пропускную способность.
1. Увеличит ли большой стек всегда длительность STW-паузы пропорционально своему размеру?
Нет. Значительная часть сканирования стеков выполняется конкурентно, поэтому размер стека не переводится напрямую в такую же по длительности остановку всех пользовательских горутин. Он увеличивает общий объём работы GC, а конкретное влияние на паузы зависит от фазы цикла, числа процессоров, темпа аллокаций и конкуренции за CPU.
Кроме того, на длительность финальной STW-фазы влияют незавершённая маркировка, обработка барьеров записи и другие операции завершения цикла. Поэтому по одному размеру стеков нельзя точно предсказать паузу; его нужно рассматривать вместе с профилем GC и нагрузкой.
2. Имеет ли значение стек горутины, если в нём нет указателей на heap?
Да, но влияние обычно меньше. Runtime должен использовать карту указателей и проверить области, где потенциально могут находиться ссылки, однако отсутствие найденных указателей сокращает дальнейший обход объектов.
Стек без ссылок на heap не удерживает объекты живыми, но его размер всё равно может участвовать в стоимости сканирования. Поэтому крупные локальные массивы числовых данных и большое количество глубоких стеков — разные проблемы: первые главным образом увеличивают объём проверки, вторые могут также увеличивать граф достижимости.
3. Следует ли уменьшать число горутин только ради снижения нагрузки GC?
Не всегда. Горутины дешёвы относительно системных потоков, а их увеличение может быть оправдано ожиданием ввода-вывода или требуемой изоляцией задач. Механическое сокращение их числа способно привести к блокировкам, росту очередей и ухудшению пропускной способности.
Правильная цель — убрать лишние одновременно активные горутины и ограничить неуправляемую конкурентность. Решение принимают по измерениям: сопоставляют число горутин, размеры стеков, CPU-профиль, паузы GC, задержки и загрузку очередей.