Обеспечивает ли запись полета JMC полную сборку мусора?

Я испытываю некоторые проблемы, связанные с производительностью (большую часть времени работает нормально, и время от времени наблюдается всплеск времени отклика со 100 мс до 4/5 без видимой причины) в службах, реализованных в OSB. Одна из гипотез, объясняющих эту ситуацию, заключается в том, что JVM может выполнять полный сбор мусора во время этих всплесков, и мы отслеживаем JVM с помощью управления миссией.

Администраторы говорят мне, что jvm работает с полностью отключенным gc, используя G1GC, и я вижу это в команде запуска:

-XX:+DisableExplicitGC  
-XX:+UseG1GC 
-XX:MaxGCPauseMillis=500 -verbosegc 
-XX:+PrintGCDetails 
-XX:+PrintGCDateStamps

Кроме того, когда я анализирую журналы gc, не ведется регистрация выполненных полных сборщиков мусора, я мог только найти (что имеет смысл на основе этих конфигураций):

2017-05-02T04:46:10.916-0700: 39228.353: [GC pause (G1 Evacuation Pause) (young), 0.0173177 secs]

Однако, как только я включил бортовой регистратор в jmc и начал какое-то нагрузочное тестирование, я сразу заметил, что выполняются полные сборщики мусора.

Пример полного сборщика мусора

и я вижу это в журналах:

2017-05-02T05:41:31.297: 548.719: [Full GC (Heap Inspection Initiated GC) 1780->705M(2048M), 3.040 secs]

Как только я отключу бортовой регистратор, я могу запускать один и тот же нагрузочный тест снова и снова, и в журналах не будет записано никаких полных сборщиков мусора.

Мне что-то здесь не хватает, или Flight Recorder действительно заставляет JVM выполнять полный сборщик мусора?

С Уважением


java garbage-collection jfr jmc osb
person Fabio    schedule 03.05.2017    source источник

Ответы (3)


arrow_upward
2
arrow_downward

Об этом говорится в документации :

Запись полета, созданная с включенной статистикой кучи, будет начинаться и заканчиваться старым сборщиком мусора. Выберите этот старый сборщик мусора в списке сборщиков мусора, а затем выберите вкладку «Общие», чтобы увидеть причину сборщика мусора как - Heap Inspection Initiated GC. Эти сборщики мусора обычно занимают немного больше времени, чем другие сборщики мусора.

person the8472    schedule 03.05.2017

arrow_upward
0
arrow_downward

Если вы включите статистику кучи в мастере записи, JVM остановит приложение и очистит кучу для сбора информации о нем. Если вы хотите быть уверенным в низких накладных расходах (1%), используйте шаблон записи по умолчанию (без изменений).

person Kire Haglin    schedule 03.05.2017

arrow_upward
-1
arrow_downward

Да, запись JFR запускает полный сборщик мусора с регулярными интервалами. Изначально нас тоже интересовало то же самое, но в документации ниже приведены подробные сведения.

https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr005.html.

The flight recording generated with Heap Statistics enabled will start and end with an old GC. Select that old GC in the list of GCs, and then choose the General tab to see the GC Reason as - Heap Inspection Initiated GC. These GCs usually take slightly longer than other GCs.

По сути, идея состоит в том, чтобы посмотреть на объекты, которые не собираются даже после сборки мусора, что указывает на утечку памяти.

Если вы хотите просто взглянуть на всю кучу, чтобы получить представление обо всех объектах в куче, то JFR - неправильный путь. Просто возьмите дамп кучи и просмотрите его с помощью Visual vm by java или любых других бесплатных инструментов. При создании дампа кучи также проверьте документацию команды, чтобы убедиться, что команда дампа кучи не запускает сборщик мусора. Для этого есть варианты, надо поискать.

Обновление: также в отношении гипотезы GC в вашем вопросе лучший способ - распечатать журналы GC через аргументы JVM. Доступны инструменты, которые принимают журнал GC в качестве входных данных и показывают красивые графики с читаемой статистикой. Так что просто оставьте включенными журналы GC и проведите тестирование. Затем, когда вы видите проблему / медлительность и т. Д., Посмотрите журнал GC с помощью инструментов и посмотрите, сколько времени прошло GC, сколько памяти было очищено и т. Д.

person Ravi K    schedule 21.07.2017