Что означает «уровень сбора мусора» и какую пользу это может принести?

Question

При анализе поведения Java GC у некоторых инструментов есть метрика «скорость сборки мусора» (пример может быть на рисунке 19. из http://www.ibm.com/developerworks/java/library/j-ibmtools2/#fig19), из которых единица равна МБ / с.

Это редко метрика по сравнению с другими, например, использование GC. Похоже на то, как быстро очищается GC. Но дает ли это какую-либо выгоду? Или как это лучше всего проанализировать?

Answer 1

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

Использование единицы измерения в мегабайтах / секундах обычно не очень полезно.

Я обычно рекомендую стараться не превышать 10 Мбайт на взаимодействие с пользователем.

Вы должны быть осторожны, не слишком стараясь свести к минимуму Мусор, потому что может случиться так, что вы можете ограничить параллелизм. Маркус (http://kohlerm.blogspot.com/)

Answer 2

Вы можете найти его использованным, чтобы определить некоторые причины замедления JVM в анализе производительности.
(Выписка, акцент мой)

показатель сбора мусора с разбивкой по поколениям .
Помните, что виртуальные машины Suns (1.3+) поколения и что куча разбита на «молодое поколение» и «старое поколение» в соответствии с объектом «age».
По умолчанию два разных алгоритма GC используются для управления каждым из двух поколений;

• молодое поколение использует копирующий коллектор и
• старое поколение использует коллекционер Mark Compact.

Особенности этих и других алгоритмов GC, упомянутые в этом блоге, можно найти в превосходной статье виртуальной машины Java HotSpot с турбонаддувом Sun *1022*.

_{(источник: decaresystems.ie )}

[...] Как мы можем определить, насколько сильно это увеличенное действие GC Old Generation оказало на приложение?
Хорошо, если мы сопоставим данные, которые мы теперь знаем, с другим графиком PerformaSure; На графике GC Overhead мы можем определить влияние повышенной активности GC.

Мы ясно видим, что накладные расходы растут в тандеме со скоростью GC старого поколения, в конечном итоге достигая уровня накладных расходов 100%.
Ссылаясь на график количества активных сеансов, мы видим, что увеличение активности GC и связанных с этим служебных данных фактически совпадает с подключением другого пользовательского сообщества к сети, увеличивая количество одновременных активных сеансов приблизительно с 200 до 250 и в зависимости от обстоятельств и рабочей нагрузки. иногда 300 сеансов.

Answer 3

Помимо очевидного использования этой метрики для понимания использования в программах недолговечных объектов, большинство инструментов, имеющих эту метрику, скорость сбора мусора в МБ / с, используют ее как способ измерения того, насколько хорошо работают приложения.

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

Типичным сценарием использования будет сравнение до / после номера для исправления кода. Если число увеличивается, это обычно (вы знаете, не всегда) означает лучше.

Answer 4

Поскольку это МБ / с, я бы предположил, что это означает "МБ памяти, освобождаемой сборщиком мусора в секунду".

Что касается того, насколько это значимо: диаграмма, на которую вы ссылаетесь, также предоставляет «количество сборок мусора» и «средняя пауза сбора мусора [мс]». Вы должны посмотреть на все эти числа вместе, чтобы выяснить, есть ли проблема.

Сама метрика, вероятно, просто показывает, используете ли вы много «временных» объектов (чтобы освободить большие куски) или нет. Если у вас много пауз и сборов, но только относительно мало освобожденных МБ, вы исчерпываете объем памяти и вам нужно либо добавить больше памяти, либо уменьшить ее потребление.