Какие последствия для кучи имеет неперемещающий сборщик мусора Go?
Неперемещающий сборщик мусора не уплотняет живые объекты после сборки, поэтому между ними могут оставаться свободные фрагменты. Это упрощает работу с указателями и снижает стоимость GC, но может привести к внутренней фрагментации, менее эффективному повторному использованию памяти и тому, что RSS процесса не сразу уменьшается.
Перемещение объектов требует находить и исправлять все указатели на них. Для рантайма это усложняет работу с указателями, стеками, отражением, низкоуровневым кодом и взаимодействием с внешними библиотеками.
Поэтому сборщик мусора Go использует преимущественно конкурентную разметку и освобождение, не перемещая живые объекты. Такой подход уменьшает необходимость в длительных паузах на уплотнение памяти и делает адреса объектов стабильными на протяжении их жизни с точки зрения реализации рантайма.
После освобождения объектов память может быть свободна суммарно, но разделена на небольшие области. Крупный новый объект не всегда сможет занять эти области, если они не подходят по размеру или находятся в разных страницах.
В результате приложение может запрашивать новые страницы у аллокатора или операционной системы, хотя общий объём свободной памяти внутри кучи уже велик. Это повышает потребление памяти и может ухудшить локальность данных, но само по себе не означает утечку.
Сборщик определяет живые объекты, освобождает память, занятую недостижимыми объектами, но не переносит оставшиеся объекты в единый непрерывный диапазон. Указатели на живые объекты поэтому не требуется массово обновлять во время уплотнения.
Аллокатор Go частично смягчает проблему. Куча разбита на страницы и спаны, а небольшие объекты распределяются по size-классам. Освободившиеся места обычно повторно используются для объектов подходящего размера, поэтому фрагментация не равна простому накоплению всех свободных байтов в бесполезном виде.
Для крупных объектов последствия могут быть заметнее: подходящий непрерывный диапазон может отсутствовать, даже если свободной памяти достаточно. Кроме того, освобождение объекта не обязано немедленно уменьшать RSS: рантайм может оставить страницы в резерве для будущих аллокаций или вернуть их операционной системе позже через scavenging.
Есть важный компромисс. Отсутствие перемещения упрощает поддержку указателей и снижает сложность GC, но лишает рантайм возможности регулярно уплотнять кучу. Поэтому при расследовании роста памяти нужно различать живую кучу, свободную память внутри выделенных страниц и память, фактически возвращённую ОС.
Сервис обрабатывает изображения: небольшие временные буферы живут недолго, а отдельные большие буферы живут дольше. После пиков нагрузки график живой памяти возвращается почти к исходному уровню, но RSS остаётся высоким, а новые большие аллокации периодически требуют дополнительных страниц.
Вариант с принудительным вызовом GC не устраняет фрагментацию: он освобождает недостижимые объекты, но не перемещает живые. Агрессивное уменьшение GOGC может чаще запускать сборку и снижать объём временной памяти, однако увеличит CPU-затраты и не гарантирует уплотнения.
Практичнее ограничить размеры буферов, переиспользовать объекты совместимого размера, отделить долгоживущие данные от краткоживущих и измерить heap-профиль вместе с RSS. Если после этого рантайм может вернуть свободные страницы ОС, RSS снизится; если страницы фрагментированы живыми объектами, одного GC будет недостаточно.
Нет. Сборщик сначала освобождает объекты, а рантайм может передать полностью или частично свободные страницы механизму scavenging и вернуть их ОС. Но страницы, содержащие живые объекты или неудобно расположенные свободные области, вернуть полностью нельзя.
Нет. RSS включает страницы, которые рантайм удерживает для будущих аллокаций, служебную память, стеки горутин и другие отображённые области. Нужно сравнивать профиль живой кучи, статистику аллокаций и показатели возвращённой ОС памяти, а не делать вывод только по RSS.
Принудительный GC ускоряет обнаружение и освобождение недостижимых объектов, но не изменяет адреса живых объектов. Следовательно, он может уменьшить объём занятой живыми объектами памяти, но не выполняет дефрагментацию; частые ручные запуски обычно лишь добавляют CPU-затраты и могут ухудшить задержки.