Что такое «jvm.g c .time» в Elasti c APM и как его использовать?

Question

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

Elasti c APM будет отслеживать jvm.gc.time, который сайт Elasti c определяет как:

Приблизительное суммарное время сбора в миллисекундах. Источник

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

Когда я читаю это значение два раза, получается второе, а позже чтение, на самом деле ниже, чем первое.

Первое чтение

• Пн Мар 23 14: 27 : 40 CDT 2020
• jvm.gc.time = 2384

Второе чтение

• Пн Мар 23 14: 30 : 41 CDT 2020
• jvm.gc.time = 2292

Может кто-нибудь помочь мне понять, что захватывает jvm.gc.time?

Answer 1

Эти метрики получены непосредственно из java .lang.management.GarbageCollectorMXBean . Значение jvm.gc.time metri c взято из GarbageCollectorMXBean.getCollectionTime, которое действительно накапливается с момента запуска процесса.

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

1. Процесс перезапущен.
2. Значения приведены для двух разных "менеджеров памяти" G C (например, G1 Young Поколение, G1 (Старое поколение) *

Если бы процесс был перезапущен (о чем я в любом случае ожидал бы знать), документы метрик в Elasticsearch имели бы разные значения для поля agent.ephemeral_id.

Более вероятный ответ: вы видите значения для двух разных менеджеров памяти / G C поколений, и в этом случае документы метрик в Elasticsearch будут иметь разные значения для поля labels.name.