После того как сборщик мусора освободил большую часть объектов, RSS процесса почти не уменьшился. Каким механизмом Go объясняет такое поведение?
Сборка мусора освобождает недостижимые объекты внутри управляемой кучи, но это не означает немедленного уменьшения RSS процесса. Освободившиеся страницы могут остаться у рантайма для последующих аллокаций; отдельный механизм — scavenger — возвращает неиспользуемые страницы операционной системе.
Поэтому после GC приложение может иметь меньше живых объектов, но сохранять прежний или близкий RSS. Это обычно означает не утечку объектов, а различие между освобождением памяти для Go и возвратом физических страниц ОС.
Автоматическое управление памятью решает проблему ручного освобождения объектов: разработчик не должен явно определять момент удаления каждого объекта и рисковать двойным освобождением или обращением к уже освобождённой памяти.
Однако немедленный возврат каждой освобождённой страницы операционной системе был бы дорогим: последующая аллокация потребовала бы новых системных операций. Поэтому рантайм разделяет две задачи: GC определяет, какие объекты больше не нужны, а управление кучей повторно использует освободившееся пространство.
Представим сервис, который временно обработал большой объём данных. После завершения обработки большинство временных объектов стало недостижимым, и GC их обнаружил, но RSS остался высоким.
Если ошибочно считать RSS точным объёмом живых объектов, можно принять нормальное поведение рантайма за утечку. Если же ожидать немедленного возврата всей памяти ОС, можно без необходимости запускать принудительные сборки или ограничивать рабочие буферы, ухудшая производительность.
Во время трассирующей сборки мусора Go определяет достижимые объекты. Память недостижимых объектов становится свободной внутри арены кучи и может использоваться для новых аллокаций. На этом этапе память уже не занята живыми объектами, но соответствующие страницы могут по-прежнему учитываться в адресном пространстве и RSS процесса.
Scavenger анализирует свободные страницы и при подходящих условиях возвращает физическую память операционной системе. Возврат происходит не обязательно сразу после конкретного GC: рантайм учитывает стоимость этой операции, вероятность повторного использования страниц и текущие потребности кучи.
Важно различать показатели:
Даже уменьшение HeapAlloc не обязано приводить к такому же уменьшению RSS. На RSS влияют стеки горутин, библиотеки, структуры рантайма, память сторонних аллокаторов и особенности операционной системы.
Принудительный вызов освобождения памяти может быть полезен в специальном сценарии, например после гарантированно редкой фазы пикового потребления. Но регулярное принуждение рантайма к GC или возврату страниц увеличивает CPU-затраты и может ухудшить задержки. Обычно правильнее уменьшать удержание объектов и контролировать скорость аллокаций, а не подгонять RSS частыми принудительными вызовами.
Сервис периодически формировал большой отчёт. После завершения запроса живые данные освобождались, но RSS оставался повышенным, хотя новые отчёты использовали значительную часть этой памяти повторно.
Рассматривались два варианта. Первый — вызывать принудительную сборку и освобождение памяти после каждого отчёта: это могло уменьшить RSS, но добавляло CPU-затраты и задержки. Второй — проверить профили удержания памяти, ограничить размер временных буферов и позволить рантайму повторно использовать свободную кучу; этот вариант сохранял высокий RSS после пика, но избегал повторных аллокаций.
Выбрали второй вариант, потому что память была доступна для последующих запросов, а утечки достижимых объектов не обнаружилось. Принудительное освобождение оставили только для редких операций обслуживания, где важнее снизить RSS, чем сохранить минимальную задержку.
1. Означает ли уменьшение HeapAlloc обязательное уменьшение RSS?
Нет. HeapAlloc показывает объём памяти живых объектов, а RSS — физическую память, закреплённую за процессом в более широком смысле. Свободные страницы Go-кучи могут ещё не быть возвращены ОС, кроме того, RSS включает стеки, служебные структуры и память, выделенную вне управляемой кучи.
2. Освобождает ли GC память операционной системе сразу после каждой сборки?
Нет. Основная задача GC — удалить недостижимые объекты и сделать занимаемое ими пространство доступным для аллокатора Go. Возврат страниц ОС выполняет scavenger, который работает по отдельной логике и не обязан синхронно завершаться с каждой сборкой.
3. Является ли высокий RSS после кратковременного пика доказательством утечки?
Нет. Это может быть нормальным удержанием свободных страниц для будущих аллокаций. Для диагностики нужно сравнить профиль живых объектов после GC, динамику HeapAlloc и HeapInuse, объём HeapReleased, а также проверить внешние источники памяти и длительность удержания ссылок; сама величина RSS недостаточна для вывода об утечке.