Распространение, вызванное ведением журнала унифицированного сборщика мусора Java

Как известно большинству из вас, ведение журнала сборщика мусора не стандартизировано. Формат журнала GC зависит от поставщика JVM (Oracle, IBM, HP, Azul, …), версии Java (1.4, 5, 6, 7, 8, 9), алгоритма GC (последовательный, параллельный, CMS, G1, Shenandoah) и GC системные свойства, которые вы передаете (-XX:+PrintGC, -XX:+PrintGCDetails, -XX:+PrintGCDateStamps, -XX:+PrintHeapAtGC …). На основе этих перестановок и комбинаций уже существует более 40 различных форматов журнала GC.

Какие проблемы возникают при использовании разных форматов журналов GC?
Если вы разработали какой-либо сценарий, который анализирует журналы GC для извлечения определенной статистики или запуска предупреждений, когда время GC превышает определенный порог, или отслеживает повторяющиеся события полного GC, эти сценарии необходимо настроить для работы с различными форматами журналов GC.
Поскольку существует так много разных форматов журнала GC, сложно понять каждый из форматов и эффективно интерпретировать результаты. Большинство форматов не имеют никакой документации или литературы (конечно, на этот пункт можно возразить: вы можете использовать сложные инструменты анализа журнала GC, такие как GCeasy, HPJmeter…).

Объединение или распространение?
Когда мы услышали новость о том, что в Java 9 журналы сборщика мусора повторно реализованы с использованием «унифицированного Структура ведения журнала JVM (JEP 158)Мы были в восторге, потому что думали, что все эти более 40 различных форматов журналов сборщика мусора будут объединены в один стандартный формат журнала сборщика мусора. Жизнь стала бы блаженством. Но, к сожалению, эта унифицированная структура ведения журналов сборщика мусора сделала обратное. В итоге это привело к созданию еще большего количества форматов журналов. .

Целью Unified JVM Logging framework является введение общей системы ведения журналов для всех компонентов JVM, т.е. компилятора, GC, загрузчика классов, метапространства, svc, jfr… Таким образом, в каждой строке журнала печатается следующая информация в дополнение к текущей информации, которая присутствует в старая версия GC Logs:

1. Имя компонента (компилятор, сборщик мусора, загрузчик классов, метапространство, svc, jfr…)
2. Уровень журнала (трассировка, отладка, информация, предупреждение, ошибка)
3. Украшения (time, uptime, timemillis, uptimemillis, timenanos, uptimenanos, pid, tid)
   Помимо этих дополнительных параметров, также изменился формат отчетов журнала GC. См. журнал G1 GC и журнал CMS GC между Java 8 и Java 9:

Рис. 1. Формат журнала G1 GC в унифицированной среде GC Logging Java 9

Рис. 2: Формат журнала G1 GC в Java 8

Рис. 3. Формат журнала CMS GC в унифицированной среде GC Logging Java 9.

Рис. 4. Формат журнала CMS GC в Java 8

Прежде чем читать дальше, сделайте паузу на несколько секунд и внимательно просмотрите рис. 1, рис. 2, рис. 3, рис. 4. Вы сможете четко увидеть разницу в том, насколько форматы журнала GC значительно различаются между Java 8 и Java 9. Это просто разница между Oracle Java 8 и Oracle Java 9 для алгоритмов G1 и CMS GC. Кроме того, есть другие алгоритмы GC (параллельный, CMS, Shenandoah), другие версии Java (Java 1.4, 5, 6, 7), другие поставщики JVM (Oracle, IBM, HP, Azul), другие системные свойства GC ( -XX:+PrintGC, -XX:+PrintGCDetails, -XX:+PrintGCDateStamps, -XX:+PrintHeapAtGC…). Когда вы помещаете эти комбинации сюда, количество форматов журнала GC взрывается.

Таким образом, вы можете видеть, как инфраструктура ведения журналов Unified GC усложняет (и без того усложняет) пространство формата журнала GC.

Вывод
Легче жаловаться и критиковать любую реализацию. Тем не менее, мы понимаем и уважаем полученный командой инженеров Oracle мандат на переход на унифицированную среду ведения журналов JVM. Поскольку это глобальная инициатива JVM, ведение журнала сборщика мусора попало в эту сложную ситуацию.

Чтобы помочь нам в этой сложной ситуации, мы можем использовать такие инструменты, как GCeasy, HPJmeter…. который может анализировать большинство форматов журналов GC.

Биография автора:
Рам Лакшманан
Каждый божий день миллионы и миллионы людей в Северной Америке — банки, туристы и коммерция — используют приложения, разработанные Рамом Лакшмананом. Рам является признанным докладчиком на крупных конференциях по темам масштабируемости, доступности и производительности. Недавно он основал стартап, специализирующийся на устранение проблем с производительностью.