В Go-сервисе при резком росте скорости аллокаций горутины начинают тратить CPU на маркировку объектов. Каким механизмом сборщик мусора переносит часть своей работы на приложение?
Это mutator assist — помощь сборщику со стороны горутин, выполняющих пользовательский код. Во время конкурентной фазы маркировки быстро аллоцирующая горутина получает обязанность выполнить часть mark work; поэтому время её аллокации может включать работу GC, а не только выдачу памяти.
Механизм позволяет поддерживать темп маркировки относительно темпа аллокаций и не допускать неконтролируемого роста доли ещё не обработанной памяти. Цена — дополнительная задержка и CPU-нагрузка непосредственно в приложении.
Полностью останавливать приложение на время каждой сборки дорого для серверных программ с требованиями к задержкам. Поэтому Go использует конкурентную маркировку: значительная часть работы GC выполняется одновременно с горутинами приложения.
Одной фоновой работы сборщика недостаточно. Если приложение выделяет память быстрее, чем GC успевает её просматривать, маркировка начинает отставать. Mutator assist появился как механизм обратного давления: тот, кто создаёт больше объектов, участвует в их обработке.
Предположим, сервис получает всплеск запросов, каждый из которых создаёт много временных объектов. Живая память может расти незначительно, но скорость аллокаций становится высокой, и фоновые GC-воркеры перестают успевать поддерживать требуемый темп маркировки.
Без ограничивающего механизма сборка могла бы завершаться слишком поздно, а heap — расти быстрее ожидаемого. При включении помощи горутины начинают тратить время на маркировку, из-за чего растут CPU-затраты и задержки обработки запросов; это иногда ошибочно принимают за обычное замедление бизнес-логики.
Во время конкурентной маркировки GC отслеживает баланс между объёмом выделений и объёмом выполненной mark work. Аллокация увеличивает объём памяти, который должен быть обработан текущим циклом, поэтому для быстро аллоцирующей горутины формируется большее количество работы GC.
Когда приложение выполняет аллокацию, runtime может направить горутину на assist: она выполняет маркировку доступных объектов вместо того, чтобы немедленно продолжить пользовательскую работу. После выполнения требуемой части работы аллокация или дальнейшее выполнение продолжается.
Assist не означает, что горутина полностью превращается в GC-воркер на весь цикл. Обычно это дозированная работа, рассчитываемая через pacing GC. Фоновые маркеры продолжают работать, а assists помогают удерживать общий темп в пределах, при которых heap не выходит за целевой рост.
Особенно заметен эффект у короткоживущих объектов: они увеличивают поток аллокаций, даже если почти не увеличивают объём живых данных. На практике это может проявляться как рост CPU в runtime, ухудшение latency и снижение пропускной способности при том же объёме прикладной работы.
Снижение assists обычно ищут в уменьшении объёма или частоты аллокаций: переиспользуют подходящие буферы, сокращают временные объекты, меняют формат промежуточных данных или устраняют лишние преобразования. sync.Pool может помочь для безопасно переиспользуемых временных объектов, но не должен использоваться как способ гарантированного хранения: runtime вправе очищать его содержимое.
Увеличение GOGC может реже запускать циклы GC и уменьшить суммарную частоту assists, но ценой большего heap и потенциально более долгой обработки цикла. Увеличение числа CPU или GOMAXPROCS иногда даёт сборщику больше ресурсов, однако не устраняет саму высокую скорость аллокаций и не гарантирует исчезновение assists.
В сервисе сериализации профилирование показало, что во время пиков горутины проводили заметную часть CPU-времени в runtime, а latency возрастала вместе с частотой аллокаций. Живая память при этом оставалась почти стабильной, поэтому проблема была не в утечке, а в большом потоке временных объектов и вызванных им assists.
Первый вариант — повысить GOGC. Он мог снизить частоту циклов, но увеличивал допустимый размер heap и переносил проблему на периоды ещё более высокой нагрузки. Второй вариант — без разбора добавить sync.Pool; он уменьшал бы аллокации, но усложнял владение объектами и мог ухудшить предсказуемость использования памяти.
Выбранным решением стало устранение лишних промежуточных объектов в горячем пути и переиспользование ограниченного набора буферов с ясным временем жизни. В результате снизился поток аллокаций, а вместе с ним — потребность в mutator assist; изменение GC-настроек после этого стало вторичным, а не заменой оптимизации источника нагрузки.
Ответ: Не обязательно. Assist определяется не только текущей загрузкой фоновых воркеров, но и требуемым pacing-балансом между аллокациями и маркировкой. Даже при наличии свободного CPU runtime может возложить часть работы на аллоцирующую горутину, чтобы сохранить нужное соотношение темпов и не позволить объёму необработанной работы расти.
Ответ: Assists зависят прежде всего от скорости аллокаций в течение цикла, а не только от размера набора живых объектов. Приложение может создавать и быстро терять множество небольших объектов: итоговый live heap будет умеренным, но маркировать и учитывать большое количество новых объектов всё равно потребуется.
Ответ: Нет. Такой рост также вызывают сама работа приложения, write barrier, фоновые GC-фазы, конкуренция за память и планировщик. Гипотезу проверяют профилированием CPU и runtime-метрик, сопоставляя пики задержек и аллокаций с активной фазой GC; одного факта увеличения CPU недостаточно.