1 Вопрос: Для какого размера кучи в начале GC, в конце GC и живых чисел кучи от gctrace = 1 обозначают?

вопрос создан в Wed, May 8, 2019 12:00 AM

Установка GODEBUG=gctrace=1 приводит к тому, что сборщик мусора Go выдает единственную строку со стандартной ошибкой о внутренней информации о каждом раунде GC. Допустим, у меня есть этот вывод:

gc 1 @0.021s 0%: 0.15+0.37+0.25 ms clock, 3.0+0.19/0.39/0.60+5.0 ms cpu, 4->4->0 MB, 5 MB goal, 48 P
gc 2 @0.024s 0%: 0.097+0.94+0.16 ms clock, 0.29+0.21/1.3/0+0.49 ms cpu, 4->4->1 MB, 5 MB goal, 48 P
gc 3 @0.027s 1%: 0.10+0.43+0.17 ms clock, 0.60+0.48/1.5/0+1.0 ms cpu, 4->4->0 MB, 5 MB goal, 48 P
gc 4 @0.028s 1%: 0.18+0.41+0.28 ms clock, 0.18+0.69/2.0/0+0.28 ms cpu, 4->4->0 MB, 5 MB goal, 48 P
gc 5 @0.031s 1%: 0.078+0.35+0.29 ms clock, 1.1+0.26/2.0/0+4.4 ms cpu, 4->4->0 MB, 5 MB goal, 48 P
gc 6 @0.032s 1%: 0.11+0.50+0.32 ms clock, 0.22+0.99/2.3/0+0.64 ms cpu, 4->4->0 MB, 5 MB goal, 48 P
gc 7 @0.034s 1%: 0.18+0.39+0.27 ms clock, 0.18+0.56/2.2/0+0.27 ms cpu, 4->4->0 MB, 5 MB goal, 48 P
gc 8 @0.035s 2%: 0.12+0.40+0.27 ms clock, 0.12+0.63/2.2/0+0.27 ms cpu, 4->4->0 MB, 5 MB goal, 48 P
gc 9 @0.036s 2%: 0.13+0.41+0.26 ms clock, 0.13+0.52/2.2/0+0.26 ms cpu, 4->4->0 MB, 5 MB goal, 48 P
gc 10 @0.038s 2%: 0.099+0.51+0.20 ms clock, 0.19+0.56/1.9/0+0.40 ms cpu, 4->5->0 MB, 5 MB goal, 48 P
gc 11 @0.039s 2%: 0.10+0.46+0.20 ms clock, 0.10+0.23/1.3/0.005+0.20 ms cpu, 4->4->0 MB, 5 MB goal, 48 P
gc 12 @0.040s 2%: 0.066+0.46+0.24 ms clock, 0.93+0.40/1.7/0+3.4 ms cpu, 4->4->0 MB, 5 MB goal, 48 P
gc 13 @0.041s 2%: 0.099+0.30+0.20 ms clock, 0.099+0.60/1.7/0+0.20 ms cpu, 4->4->0 MB, 5 MB goal, 48 P
gc 14 @0.042s 2%: 0.095+0.45+0.24 ms clock, 0.38+0.58/2.0/0+0.98 ms cpu, 4->5->0 MB, 5 MB goal, 48 P
gc 15 @0.044s 2%: 0.095+0.45+0.21 ms clock, 1.0+0.78/1.9/0+2.3 ms cpu, 4->4->0 MB, 5 MB goal, 48 P
gc 16 @0.045s 3%: 0.10+0.45+0.23 ms clock, 0.10+0.70/2.1/0+0.23 ms cpu, 4->5->0 MB, 5 MB goal, 48 P
gc 17 @0.046s 3%: 0.088+0.40+0.17 ms clock, 0.088+0.45/1.9/0+0.17 ms cpu, 4->4->0 MB, 5 MB goal, 48 P
.
.
.
.
gc 6789 @9.998s 12%: 0.17+0.91+0.24 ms clock, 0.85+1.8/5.0/0+1.2 ms cpu, 4->6->1 MB, 6 MB goal, 48 P
gc 6790 @10.000s 12%: 0.086+0.55+0.24 ms clock, 0.78+0.30/4.2/0.043+2.2 ms cpu, 4->5->1 MB, 6 MB goal, 48 P

Определить эти значения можно в документе :

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

where the fields are as follows:
gc #       the GC number, incremented at each GC
@#s        time in seconds since program start
#%         percentage of time spent in GC since program start
#+...+#    wall-clock/CPU times for the phases of the GC
#->#->#    MB heap size at GC start, at GC end, and live heap
# MB goal  goal heap size
# P        number of processors used

Что меня действительно смущает, так это #->#-># MB heap size at GC start, at GC end, and live heap.

  • Правильно ли, что при каждом раунде сборщик мусора освобождает ОС некоторое количество неиспользуемой (мусорной) памяти, что должно уменьшить размер кучи? Если да, то почему некоторые значения кучи увеличиваются? Например: 4-> 5-> 0. У нас было 4 МБ памяти, включая мусор, до запуска GC. Тогда как можно получить 5 МБ памяти после того, как мы очистили от нее мусор?

  • Третье значение - размер динамической кучи. В чем разница между обычным размером кучи? Я полагаю, что это куча без мусора.

  • Как рассчитывается размер кучи цели? Правильно ли это размер кучи, который GC хочет достичь после очистки? Тогда почему это значение больше размера кучи перед запуском GC?

1
  1. Чтобы прояснить сказанное ниже, GC вообще не несет ответственности за освобождение памяти для операционной системы (отдельный мусорщик обрабатывает это, хотя и сообщает об этом в выводе gctrace если это работает). GC занимается только управлением выделенной памятью. Что касается цели, прочитайте документацию по переменной env GOGC.
    2019-05-08 18: 25: 05Z
1 ответ                              1                         

GC очищает некоторое количество мусора за каждый проход. Он не обязательно выпускает его в ОС (если он думает, что просто должен будет запросить его снова в ближайшее время); и если это так, ОС не обязательно восстанавливает его (пока не возникнет нехватка памяти от другого процесса, ОС может оставить эту память выделенной для вашего процесса в случае, если она понадобится снова).

Размер динамической кучи - это то, сколько кучи активно используется, за вычетом мертвых объектов и свободного пространства кучи, готовых к будущему выделению. Размер кучи цели - это объем памяти, который, по мнению GC, должен получить от ОС для постоянной обработки выделений вашего процесса без необходимости постоянно запрашивать больше памяти у ОС (т. Е. Сколько остается в живых + сколько выделяется и отбрасывается между GC работает).

Цель GC - очистить мертвые объекты в куче, и , чтобы поддерживать достаточно свободного места в куче для обработки большинства выделений без необходимости запрашивать больше памяти у ОС (что медленно), при этом также не сохраняя чрезмерно свободной памяти (так что ОС все еще может выделять другим процессам).

    
1
2019-05-08 16: 52: 10Z
источник размещен Вот