Введение

Сборщик мусора (GC) отвечает за очистку памяти в разделе кучи основной памяти, которая становится недоступной, например, указатель, указывающий на эту память в куче, теперь установлен на nil. Отлично! Нам не нужно вручную free поднимать кучу, как это требуется в языке программирования C. Но у каждого преимущества есть свои недостатки. Сборщик мусора занимает процессорное время, которое в противном случае могло бы быть использовано для запуска приложения. Иногда это может быть очень дорого для процессора!

Чтобы справиться с этим сценарием, Golang GC использует механизм ограничения GC, в первую очередь с помощью переменной среды с именем GOGC. Это процентное соотношение New Heap к Live Heap, до которого GC не должен запускаться. Позвольте мне объяснить это на примере, если Новая куча (т.е. память, накопленная в разделе кучи, которая в данный момент не используется в работающем приложении) составляет GOGC % от Живой кучи (т. е. объем памяти кучи, который в данный момент используется программой), то будет выполняться сборщик мусора для очистки кучи. Таким образом, если для GOGC установлено значение 100 (значение по умолчанию), то сборщик мусора запустится, когда память новой кучи удвоится по сравнению с оперативной памятью кучи.

Новая особенность

Но в последней версии GC появилась новая функция, позволяющая напрямую устанавливать лимит памяти, при котором должен работать GC, вместо использования GOGC в качестве коэффициента. Итак, если, скажем, оперативная память обычно составляет 20 МБ, вы можете установить предел памяти (вы можете использовать runtime.SetMemoryLimit) до 45 МБ, чтобы срабатывал всякий раз, когда размер кучи памяти достигает этого. Итак, теперь вы можете установить GOGC=off, чтобы никогда не запускать сборщик мусора, но запускать его, если и когда мы достигнем предела! Это здорово, но в других языках эта функция была очень давно 😂 Причина задержки в том, что, хотя установка лимита памяти кажется тривиальной, по сути, сборщик мусора может запускаться очень часто, если лимит не установлен должным образом, что приводит к очень низкой производительности приложения! Сборщик мусора обрабатывает и эту ситуацию, поэтому, если сборщик мусора занимает 50% ЦП более 2 секунд, сборщик мусора будет остановлен. Этот механизм все еще обсуждается, но со временем будет развиваться.

Заключение

Итак, в заключение, GOGC должен быть установлен в соответствии с нашим ограничением памяти и процессора, что для нас более ценно! Установка GOGC на более низкое значение с частым триггером GC приводит к меньшему использованию памяти, но большему использованию ЦП. С другой стороны, установка более высокого процента приведет к увеличению использования памяти, но снижению загрузки ЦП. Таким образом, цель должна заключаться в том, чтобы протестировать различные сценарии и найти золотую середину, и о, теперь вы также можете отключить ее!

Рекомендации

  1. https://tip.golang.org/doc/gc-guide
  2. Go day 2022, который произошел 3 ноября 2022 года.

Первоначально опубликовано на http://www.souvikhaldar.in 3 ноября 2022 г.