Смотрю на GC с godebug

Автор оригинала: David Wong.

Первоначальный адрес: просмотр GC с помощью godebug

Что такое GC

В информатике сборка мусора (GC) – это механизм автоматического управления памятью. Сборщик мусора пытается переработать объекты, которые больше не используются программами, и занимаемую ими память. Джон Маккарти впервые изобрел сборку мусора примерно в 1959 году, чтобы упростить механизм ручного управления памятью в LISP (из Википедии).

Почему ГК

Управлять памятью вручную довольно сложно. Также очень плохо управлять ошибкой или утечкой памяти, что напрямую приведет к нестабильности программы (непрерывной утечке) и даже прямому сбою.

Проблемы, вызванные ГК

Если вы хотите сказать, какие проблемы это принесет, это больше всего беспокоит stop the world (STW). STW относится к необходимости приостановки всего приложения для работы с рабочими элементами, связанными с GC, на определенном этапе алгоритма сбора мусора. Например:

Как настроить частоту GC

Целевое процентное значение начального сборщика мусора можно задать с помощью переменной gogc. Правило сравнения заключается в том, что, когда соотношение вновь выделенного значения к оставшемуся значению в реальном времени после последней коллекции достигает установленного целевого процента, запускается GC, и значение по умолчанию равно. Если вы установите это значение, вы можете полностью отключить сборщик мусора, разве вы не пытаетесь?

Короче говоря, чем больше задано значение gogc, тем ниже частота GC. Однако объем памяти кучи, в конечном итоге инициируемый для GC, будет увеличиваться с каждым разом.

GC каждой версии

Примечание: данные получены из совместного использования @ Boya в gopher meetup, Шэньчжэнь.

БОЖИЙ ЖУК

Переменная go debug может управлять переменными отладки во время выполнения. Параметры разделены запятыми, и формат: name=val . В этой статье основное внимание уделяется наблюдению за GC, в основном связанным с параметрами трассировки gc, мы установили gctrace=1 После этого сборщик мусора может отправлять информацию о выполнении GC в стандартный поток ошибок.

Соответствующие условия

• Отметка: этап маркировки.
• Прекращение пометки: Прекращение пометки.
• Помощь мутатору: вспомогательный GC означает, что во время процесса GC потоки мутатора будут выполняться одновременно, и механизм помощи мутатору поможет GC выполнить некоторую работу.
• heap_ Live: в управлении памятью go, span является основной единицей страниц памяти, и размер каждой страницы составляет 8 КБ. В то же время go выделит разные страницы диапазона в соответствии с размером объекта, а heap_ Live представляет общий размер всего диапазона.
• Разделенный/дробный/холостой ход: на этапе маркировки существует три различных режима работы с метками, а именно выделенный, дробный и холостой ход. Они представляют собой различные степени концентрации. Среди них выделенный режим является наиболее целенаправленным и полным режимом восстановления GC, в то время как дробный режим фокусируется только на поведении GC, а простой-самый простой. Здесь вам просто нужно понять, что это работник марки с разной степенью концентрации. Мы можем подождать подробностей в следующих статьях.

Демонстрационный код

func main() {
    wg := sync.WaitGroup{}
    wg.Add(10)
    for i := 0; i < 10; i++ {
        go func(wg *sync.WaitGroup) {
            var counter int
            for i := 0; i < 1e10; i++ {
                counter++
            }
            wg.Done()
        }(&wg)
    }

    wg.Wait()
}

gctrace

$ GODEBUG=gctrace=1 go run main.go    
gc 1 @0.032s 0%: 0.019+0.45+0.003 ms clock, 0.076+0.22/0.40/0.80+0.012 ms cpu, 4->4->0 MB, 5 MB goal, 4 P
gc 2 @0.046s 0%: 0.004+0.40+0.008 ms clock, 0.017+0.32/0.25/0.81+0.034 ms cpu, 4->4->0 MB, 5 MB goal, 4 P
gc 3 @0.063s 0%: 0.004+0.40+0.008 ms clock, 0.018+0.056/0.32/0.64+0.033 ms cpu, 4->4->0 MB, 5 MB goal, 4 P
gc 4 @0.080s 0%: 0.004+0.45+0.016 ms clock, 0.018+0.15/0.34/0.77+0.065 ms cpu, 4->4->1 MB, 5 MB goal, 4 P
gc 5 @0.095s 0%: 0.015+0.87+0.005 ms clock, 0.061+0.27/0.74/1.8+0.023 ms cpu, 4->4->1 MB, 5 MB goal, 4 P
gc 6 @0.113s 0%: 0.014+0.69+0.002 ms clock, 0.056+0.23/0.48/1.4+0.011 ms cpu, 4->4->1 MB, 5 MB goal, 4 P
gc 7 @0.140s 1%: 0.031+2.0+0.042 ms clock, 0.12+0.43/1.8/0.049+0.17 ms cpu, 4->4->1 MB, 5 MB goal, 4 P
...

формат

gc # @#s #%: #+#+# ms clock, #+#/#/#+# ms cpu, #->#-># MB, # MB goal, # P

значение

• gc# : количество раз выполнения GC, каждый стек.
• @#s : определенное количество секунд с момента запуска программы до текущего времени.
• #% : процент времени, проведенного в GC с момента запуска программы.
• #+...+# : процент общего процессорного времени, используемого для работы с тегами GC.
• #->#-># МБ : указывает размер кучи, когда GC запускается, заканчивается и активен
• #Цель в МБ : пороговое значение потребления памяти для следующего триггера GC.
• #P : количество процессоров P, используемых в настоящее время.

дело

gc 7 @0.140s 1%: 0.031+2.0+0.042 ms clock, 0.12+0.43/1.8/0.049+0.17 ms cpu, 4->4->1 MB, 5 MB goal, 4 P

• ГК 7: 7-й ГК.
• @0,140 с: прошло 0,140 с после запуска программы.
• 1%: программа потратила 1% своего времени на GC.

• 0.031+2.0+0.042 часы ms:

  • 0,031: представляет время STW на этапе с одной меткой вывода.
  • 2.0: указывает время, используемое всеми метками P одновременно.
  • 0,042: представляет время STW этапа завершения метки одного П.

• 0.12+0.43/1.8/0.049+0.17 мс процессор:

  • 0.12: указывает время паузы STW всего процесса в фазе рынка.
  • 0.43/1.8/0.049: 0,43 указывает время, занятое помощником мутатора, 1,8 представляет время, занятое выделенным + дробным, и 0,049 представляет время, занятое простоем.
  • 0,17 мс: 0,17 указывает время STW всего процесса на этапе завершения метки.

• 4->4->1 МБ:

  • 4: Указывает на кучу до начала метки phase_ Размер в реальном времени.
  • 4: Представляет кучу до начала фазы завершения метки. Размер в реальном времени.
  • 1: Представляет размер отмеченного объекта.
• Цель 5 МБ: указывает, что пороговое значение для следующего повторного использования GC составляет 5 МБ.
• 4 P: сколько p участвует в этом GC.

резюме

В этой главе мы освоили метод использования godebug для просмотра работы GC приложения. Пока мы используем этот метод, мы можем наблюдать ситуацию с GC в разных условиях и даже составлять очень интуитивно понятную диаграмму сравнения. Вы можете также попробовать это.

Статьи по теме

• Глядя на отслеживание расписания с помощью godebug

справочные ресурсы

• В чем смысл информации, распечатанной ogc?
• Анализ отладки информации о трассировке gc
• Некоторые недоразумения по поводу golang GC — действительно ли он опережает Java GC?
• @Boya рассказывает о golang runtime ppt