Как правильно прочитать некоторые части журнала из G C с помощью "-Xlog: heap * = debug" "-Xlog: g c* = debug" - PullRequest
2 голосов
/ 06 марта 2020

Предположим, у меня очень простой код:

public class Sandbox { 

    public static void main(String[] args) {

        Map<String, Integer> map = new HashMap<>();

        while (true) {
            map.put(new Random().toString(), new Random().nextInt());
        }
    }
}

Не имеет значения, насколько он «неправильный», но что он делает. Это в конечном итоге дает OutOfMemory. Я запускаю его с:

java -Xms50M -Xmx50M "-Xlog:heap*=debug" "-Xlog:gc*=debug" Sandbox 

Будет много журналирования, я разделю их на наиболее важные части, которые меня интересуют (я также удалил некоторую информацию из некоторых строк для удобства чтения)

*****************************     GC(0)    *********************************

[0.115s][debug][gc,heap] GC(0) Heap before GC invocations=0 (full 0)
[0.115s][debug][gc,heap] GC(0) region size 1024K, 23 young, 0 survivors

[0.127s][info ][gc,heap] GC(0) Eden regions: 23->0(15)
[0.128s][info ][gc,heap] GC(0) Survivor regions: 0->3(3)
[0.128s][info ][gc,heap] GC(0) Old regions: 0->4
[0.128s][info ][gc,heap] GC(0) Archive regions: 2->2
[0.128s][info ][gc,heap] GC(0) Humongous regions: 1->1

[0.128s][debug][gc,heap] GC(0) Heap after GC invocations=1 (full 0):
[0.128s][debug][gc,heap] GC(0) region size 1024K, 3 young, 3 survivors


 *****************************     GC(1)    *********************************

[0.159s][debug][gc,heap] GC(1) Heap before GC invocations=1 (full 0)
[0.159s][debug][gc,heap] GC(1) region size 1024K, 18 young, 3 survivors

[0.181s][info ][gc,heap] GC(1) Eden regions: 15->0(1)
[0.181s][info ][gc,heap] GC(1) Survivor regions: 3->3(3)
[0.181s][info ][gc,heap] GC(1) Old regions: 4->10
[0.181s][info ][gc,heap] GC(1) Archive regions: 2->2
[0.181s][info ][gc,heap] GC(1) Humongous regions: 3->3

[0.181s][debug][gc,heap] GC(1) Heap after GC invocations=2 (full 0)
[0.181s][debug][gc,heap] GC(1) region size 1024K, 3 young, 3 survivors

*****************************     GC(2)    *********************************

[0.182s][debug][gc,heap] GC(2) Heap before GC invocations=2 (full 0)
[0.182s][debug][gc,heap] GC(2) region size 1024K, 4 young, 3 survivors 

[0.190s][info ][gc,heap] GC(2) Eden regions: 1->0(9)
[0.190s][info ][gc,heap] GC(2) Survivor regions: 3->1(1)
[0.190s][info ][gc,heap] GC(2) Old regions: 10->13
[0.190s][info ][gc,heap] GC(2) Archive regions: 2->2
[0.190s][info ][gc,heap] GC(2) Humongous regions: 3->3

[0.190s][debug][gc,heap] GC(2) Heap after GC invocations=3 (full 0)
[0.190s][debug][gc,heap] GC(2) region size 1024K, 1 young, 1 survivors

Что точно они имеют в виду?

1 Ответ

3 голосов
/ 06 марта 2020

Я нашел только две ссылки в Интернете, которые как-то объясняют это: одну здесь и другую здесь . К сожалению, ни один из них не имел особого смысла, поэтому мне пришлось взглянуть на исходный код, где он генерируется, чтобы получить понимание.

Первые строки:

[0.115s][debug][gc,heap] GC(0) Heap before GC invocations=0 (full 0)
[0.115s][debug][gc,heap] GC(0) region size 1024K, 23 young, 0 survivors

Скажите, что до первого вызова G C (0), у молодого пространства было 23 областей выделены. Это также говорит вам (косвенно), что из этих 23: 0 были выжившие регионы, что означает 23 были Eden единицы.

Следующие строки:

[0.127s][info ][gc,heap] GC(0) Eden     regions:     23 -> 0 (15)
[0.128s][info ][gc,heap] GC(0) Survivor regions:     0  -> 3 (3)

Tell Вы, что за до до GC operation были 23 районы Эдема. Все из них были очищены (это 0) (в конце концов, это причина, по которой существует молодой G C). Затем он показывает, что до G C было 0 регионов выживших, но в результате этого цикла было сгенерировано 3 Survivor Regions.

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

Этот «переход» объясняется в следующих журналах:

[0.128s][debug][gc,heap] GC(0) Heap after GC invocations=1 (full 0):
[0.128s][debug][gc,heap] GC(0) region size 1024K, 3 young, 3 survivors

Обратите внимание, как куча перешла на 3 young, 3 survivors (таким образом, 0 eden, все 23 были очищены).

После этого делается еще один шаг: будет изменено общее количество регионов. Как? Вы можете сами взглянуть на исходный код , чтобы узнать.

В частности, (3) будет вычислено здесь с более подробной информацией (и очень хорошими комментариями) здесь , в основном это говорит о том, сколько Survivor Regions будет доступно для следующий цикл G C. В большинстве случаев (3) будет равно этому ->3, для регионов выживших.

Эта «корректировка» примерно равна (15) и (3), что означает, что следующий цикл будет иметь 15 Eden Regions и 3 Survivor Regions; также обозначается журналами цикла next , в самом его начале.

[0.159s][debug][gc,heap] GC(1) Heap before GC invocations=1 (full 0)
[0.159s][debug][gc,heap] GC(1) region size 1024K, 18 young, 3 survivors

Есть один комментарий, который мне нужно сделать здесь: это подсказки для что предполагается использовать G C в следующем цикле, они могут быть проигнорированы (например, humongous allocation вызовет это).

Так что теперь мы можем нарисовать линию. В этих журналах есть две логические части.

  • Переход - как молодые регионы изменились из-за этого цикла

  • Настройка количества молодых регионов после этого перехода.


Теперь должно быть довольно легко переварить некоторые журналы, например:

[0.182s][debug][gc,heap] GC(2) Heap before GC invocations=2 (full 0)
[0.182s][debug][gc,heap] GC(2) region size 1024K, 4 young, 3 survivors

Это запущено с 4 young = 1 Eden + 3 Survivor

[0.190s][info ][gc,heap] GC(2) Eden     regions: 1 -> 0 (9)
[0.190s][info ][gc,heap] GC(2) Survivor regions: 3 -> 1 (1)

Он перешел в 0 Eden, 1 Survivor

[0.190s][info ][gc,heap] GC(2) Eden     regions: 1 -> 0 (9)
[0.190s][info ][gc,heap] GC(2) Survivor regions: 3 -> 1 (1)

Он применил heuristi c для генерации 9 Eden, 1 Survivor для следующего цикла G C.

...