Подтвердить что ты не робот

Сообщения журнала коллекции мусора Java

Я настроил java, чтобы выгрузить информацию о сборке мусора в журналы (подробный GC). Я не уверен, что означают записи коллекции мусора в журналах. Пример этих записей размещен ниже. Я искал вокруг Google и не нашел твердых объяснений.

У меня есть некоторые разумные догадки, но я ищу ответы, которые дают строгие определения того, что означают цифры в записях, подкрепленные достоверными источниками. Автоматический +1 для всех ответов, которые ссылаются на солнце документации. Мои вопросы:

  • К чему относится PSYoungGen? Я предполагаю, что это имеет какое-то отношение к предыдущему поколению, но что именно?
  • В чем разница между вторым триплетом чисел и первым?
  • Почему имя (PSYoungGen) указано для первого триплета чисел, но не второго?
  • Что означает каждый номер (размер памяти) в триплете. Например, в 109884K- > 14201K (139904K), это память до GC 109884k, а затем она уменьшена до 14201K. Как относится к третьему номеру? Зачем нам нужен второй набор чисел?

8109.128: [GC [PSYoungGen: 109884K- > 14201K (139904K)] 691015K- > 595332K (1119040K), 0.0454530 сек]

8112.111: [GC [PSYoungGen: 126649K- > 15528K (142336K)] 707780K- > 605892K (1121472K), 0,0934560 сек]

8112.802: [GC [PSYoungGen: 130344K- > 3732K (118592K)] 720708K- > 607895K (1097728K), 0,0682690 сек]

4b9b3361

ОТВЕТЫ

Ответ 1

Большая часть из них объясняется в Руководстве по настройке GC (которое вам все равно нужно прочитать).

Опция командной строки -verbose:gc приводит к тому, что информация о сборке кучи и мусора должна быть напечатана в каждой коллекции. Например, здесь выводится из большого серверного приложения:

[GC 325407K->83000K(776768K), 0.2300771 secs]
[GC 325816K->83372K(776768K), 0.2454258 secs]
[Full GC 267628K->83769K(776768K), 1.8479984 secs]

Здесь мы видим две второстепенные коллекции, за которыми следует одна крупная коллекция. Числа до и после стрелки (например, 325407K->83000K из первой строки) указывают объединенный размер живых объектов до и после сбора мусора, соответственно. После небольших коллекций размер включает в себя некоторые объекты, которые являются мусором (уже не живыми), но которые не могут быть восстановлены. Эти объекты либо содержатся в поколенном поколении, либо ссылаются на постоянные или постоянные поколения.

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

Последний элемент строки (например, 0.2300771 secs) указывает время, затраченное на выполнение коллекции; в этом случае примерно четверть секунды.

Формат основной коллекции в третьей строке аналогичен.

Формат вывода, созданного -verbose:gc, может быть изменен в будущих выпусках.

Я не уверен, почему в вашем распоряжении PSYoungGen; вы изменили сборщик мусора?

Ответ 2

  • PSYoungGen относится к сборщику мусора, который используется для небольшой коллекции. PS означает Parallel Scavenge.
  • Первый набор чисел - это размеры до и после молодого поколения, а второй набор - для всей кучи. (Диагностика проблемы с сборкой мусора подробно описывает формат)
  • Название указывает на генерацию и сборщик, о котором идет речь, второй набор для всей кучи.

Пример связанного полного GC также показывает коллекторы, используемые для старого и постоянного поколений:

3.757: [Full GC [PSYoungGen: 2672K->0K(35584K)] 
            [ParOldGen: 3225K->5735K(43712K)] 5898K->5735K(79296K) 
            [PSPermGen: 13533K->13516K(27584K)], 0.0860402 secs]

Наконец, разбив одну строку вашего выходного журнала журнала:

8109.128: [GC [PSYoungGen: 109884K->14201K(139904K)] 691015K->595332K(1119040K), 0.0454530 secs]
  • 107Mb, используемый до GC, 14Mb, используемый после GC, максимальный размер молодого поколения 137Mb
  • 675Mb куча, используемая до GC, 581Mb куча, используемая после GC, 1 ГБ максимальный размер кучи
  • младший GC произошел 8109.128 секунд с момента запуска JVM и взял 0,04 секунды

Ответ 3

Я просто хотел упомянуть, что можно получить подробный журнал GC с помощью

-XX:+PrintGCDetails

параметр. Затем вы видите вывод PSYoungGen или PSPermGen, как в ответе.

Также -Xloggc:gc.log, похоже, генерирует тот же результат, что и -verbose:gc, но вы можете указать выходной файл в первом.

Пример использования:

java -Xloggc:./memory.log -XX:+PrintGCDetails Memory

Чтобы лучше визуализировать данные, вы можете попробовать gcviewer (более позднюю версию можно найти на github).

Позаботьтесь о правильном написании параметров, я забыл "+", и мой JBoss не запустился, без каких-либо сообщений об ошибках!