Объясните, почему GOMEMLIMIT не гарантирует, что RSS Go-процесса никогда не превысит заданный предел.
GOMEMLIMIT — это мягкая цель для памяти, которую старается соблюдать рантайм Go, а не жёсткий лимит потребления процесса. RSS может превысить её из-за неизбежных временных затрат, памяти вне контроля GC, задержки возврата страниц операционной системе и ограничения на чрезмерную загрузку CPU сборщиком мусора.
Ранее частоту сборки мусора в основном регулировали через GOGC: он задаёт допустимый рост heap относительно объёма живых данных. Такой подход плохо учитывает фиксированный лимит памяти контейнера: одинаковое значение GOGC может быть безопасным для одного окружения и привести к OOM в другом.
В современных версиях Go появился GOMEMLIMIT, ориентированный на сценарии с ограниченным объёмом памяти, прежде всего в контейнерах. Он позволяет рантайму агрессивнее запускать GC и возвращать память, когда процесс приближается к заданной цели.
Если воспринимать GOMEMLIMIT как аналог жёсткого лимита контейнера, можно ошибочно решить, что превышение невозможно. На практике процесс может превысить значение, а при слишком низком лимите начать тратить значительную долю CPU на сборку мусора, не устраняя сам источник роста памяти.
Кроме того, RSS включает не только пространство объектов Go в heap. В него могут входить память стека и метаданных рантайма, машинные стеки, библиотеки, отображённые файлы и другие области, которые не освобождаются обычным циклом GC.
Рантайм оценивает объём памяти, за который отвечает Go, и изменяет темп GC так, чтобы приблизиться к memory limit. При приближении к цели сборки могут запускаться чаще, а после цикла рантайм может активнее возвращать свободные страницы ОС.
Это не превращает лимит в барьер. Во время аллокаций память нужна раньше, чем GC успеет завершить цикл и освободить страницы. Также существуют корневые и живые объекты, которые нельзя удалить, поэтому при минимальном объёме памяти ниже фактического live heap цель недостижима.
Есть и защитный компромисс: рантайм не должен бесконечно отнимать CPU у прикладного кода ради достижения слишком низкой цели. Поэтому при чрезмерно агрессивном давлении памяти лимит может быть временно превышен, вместо того чтобы полностью остановить выполнение приложения сборкой мусора.
Важно различать три величины: heap Go, память, учитываемую механизмом лимита, и RSS процесса. Они связаны, но не совпадают. Даже после успешного GC RSS может уменьшиться не сразу: страницы могут оставаться в арене рантайма или быть возвращены ОС с задержкой.
GOMEMLIMIT не заменяет лимит контейнера. Контейнерный лимит остаётся внешним жёстким ограничением; GOMEMLIMIT следует задавать ниже него, оставляя запас для памяти вне heap, служебных структур и кратковременных пиков.
Go-сервис в контейнере с лимитом 512 МБ имел GOMEMLIMIT 480 МБ. При всплеске запросов RSS иногда достигал 510–520 МБ, после чего контейнер завершался по OOM. Профиль показывал, что heap не был единственным потребителем: заметную долю занимали стеки большого числа горутин и память используемой библиотеки.
Рассматривались два варианта. Снижение GOMEMLIMIT до очень малого значения уменьшало средний heap, но вызвало частые GC-циклы и ухудшило задержки. Отказ от GOMEMLIMIT сохранял производительность в обычном режиме, но повышал риск неконтролируемого роста heap.
Выбрали умеренно меньший лимит с запасом, ограничили параллелизм обработки и уменьшили удержание временных буферов. В результате GC получил возможность заранее реагировать на рост heap, RSS перестал регулярно пересекать лимит контейнера, а задержки остались стабильнее, чем при агрессивном снижении GOMEMLIMIT.
Нет. Это оставляет слишком мало места для памяти, не совпадающей с учётом heap: стеков горутин, метаданных рантайма, нативных библиотек, mmap и кратковременных пиков. Обычно нужен запас, размер которого определяют измерениями конкретного сервиса.
Нет. GC освобождает только недостижимые объекты. Если live heap уже близок к лимиту, уменьшение GOMEMLIMIT не решит проблему: сборщик будет чаще работать, но полезные объекты останутся. В таком случае нужны уменьшение удерживаемого состояния, ограничение кэшей или изменение архитектуры обработки.
GC определяет, какие объекты больше не нужны, но возврат физических страниц ОС — отдельный этап. Часть свободной памяти может оставаться в аренах аллокатора для будущих аллокаций, а часть RSS формируется не объектами heap. Поэтому оценивать эффект нужно одновременно по heap-метрикам, статистике рантайма и RSS, а не по одному показателю.