Выделенная куча G1GC Old Gen продолжает расти, используется постоянно - приводит к голоданию Eden

Выделенная куча G1GC старого поколения со временем увеличивается (около 5–6 дней в рабочей среде), а используемая куча старого поколения — нет. Куча Эдема и оставшегося в живых вынуждена уменьшаться до минимума (5% от общей кучи) и поэтому сборка мусора, потому что все чаще и чаще. Приложение кэширует один большой граф объектов в самом начале, а затем имеет другое кэширование, ограниченное по времени/использованию, на протяжении всего срока его выполнения. Он имеет довольно высокую скорость создания объектов, но не способствует большей части этого для старого поколения, кроме кэшированных объектов.

Я прогнал журнал сборщика мусора через gceasy.io, и вы можете увидеть приведенное выше поведение памяти: "nofollow noreferrer">https://gceasy.io/my-gc-report.jsp?p=c2hhcmVkLzIwMjAvMDUvMTEvLS1nY2xvZy50YXIuZ3otLTExLTMwLTE5&channel=WEB.

gclog: https://drive.google.com/open?id=176X-Lku4D3DGCCdTiB0_z545N8n0tfKc< /а>

Показатели памяти Grafana для этого запуска /а>

Дамп кучи в конце прогона (загрузка была удалена около часа, это gz-файл размером 500 МБ): https://drive.google.com/open?id=14ghzIVnpelInSyQBhCwUwM5VkuOjX13-

Кажется, у нас нет создания больших огромных объектов. На сервере 12 ГБ оперативной памяти, а в куче — 6 ГБ.

JVM:

openjdk version "1.8.0_242"
OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_242-b08)
OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.242-b08, mixed mode)

Флаги JVM:

-XX:CICompilerCount=4
-XX:ConcGCThreads=2
-XX:G1HeapRegionSize=2097152
-XX:GCLogFileSize=104857600
-XX:InitialHeapSize=6442450944
-XX:InitialRAMPercentage=50.000000
-XX:+ManagementServer
-XX:MarkStackSize=4194304
-XX:MaxHeapSize=6442450944
-XX:MaxNewSize=3865051136
-XX:MaxRAMPercentage=50.000000
-XX:MinHeapDeltaBytes=2097152
-XX:MinRAMPercentage=50.000000
-XX:NumberOfGCLogFiles=10
-XX:+PrintGC
-XX:+PrintGCDateStamps
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+UseCompressedClassPointers
-XX:+UseCompressedOops
-XX:+UseG1GC
-XX:+UseGCLogFileRotation

Работаем на openshift с CentOS: выпуск CentOS Linux 7.7.1908 (Core)

Ядро: 3.10.0-1062.12.1.el7.x86_64


java spring-mvc garbage-collection openshift-origin g1gc
person Tom Dearman    schedule 11.05.2020    source источник
comment
Пробовали ли вы делать дамп кучи и анализировать в начале прогона, а потом через несколько дней и сравнивать?   -  person kenny_k    schedule 11.05.2020
comment
Я пробовал это и не вижу ничего особенного, в частности, фактическая используемая куча всегда намного меньше, чем зафиксированная куча. У меня есть дамп кучи на конец этого прогона, и он показывает общее использование кучи 1,3 ГБ, а старое поколение зафиксировало около 6 ГБ (я загружу ссылку). Следовательно, Эдем голодает. Я загрузил ссылку на метрики grafana, чтобы показать использование памяти, подобное тому, что показывает gceasy.   -  person Tom Dearman    schedule 11.05.2020
comment
@TomDearman У меня та же проблема (использовано ~ 2 *), вы нашли, в чем была основная причина? Когда у меня есть небольшое выделенное пространство eden + Survivor, большая часть использования процессора будет использоваться gc, и все приложение будет замедляться, даже если у меня достаточно памяти.   -  person Hamdi    schedule 26.11.2020

Ответы (1)


arrow_upward
0
arrow_downward

В общем, это нормально, что committed значение памяти выше, чем used. Committed начинается с -Xms и может доходить до -Xmx, но committed не resident. Resident здесь означает в ОЗУ, а used = resident + swapped pages. Так что used может сильно колебаться, а committed не так сильно, по крайней мере, я так это понимаю.

GC начинается со значения -Xms в качестве исходной выделенной памяти и будет медленно увеличиваться (конечно, до -Xmx). И теперь, когда я сделал это введение, я действительно не думаю, что это имеет какое-то значение для вашего приложения. Позволь мне объяснить.

Насколько я вижу из предоставленных вами логов, все в значительной степени ожидаемо (и нормально). G1 имеет значение по умолчанию для MaxGCPauseMillis = 200ms, которое указывает, насколько ваше приложение может быть остановлено (в сценарии счастливого пути). В соответствии с этим значением G1 принимает правильные решения по изменению размера ваших регионов. Согласно вашим журналам, Eden пространства из примерно 270MB (в среднем) собирается до 0.2s. Просто случайный пример из ваших журналов:

[Eden: 280.0M ....
Times: user=0.49 sys=0.00, real=0.18 secs
2020-05-04T02:43:01.742+0000: 315128.451: [GC pause (G1 Evacuation Pause) (young), 0.1740299 secs]

Так что это именно то, о чем вы просили, косвенно. Для меня ваше приложение прекрасно подходит, эти GC pause (G1 Evacuation Pause) занимают столько, сколько вы настроили. И, кстати, назвать себя счастливчиком? но во всем этом файле журнала нет ни одного Full GC, который я могу обнаружить (кроме того, когда вы берете дамп кучи).

person Eugene    schedule 09.07.2020