Дамп кучи != виртуальная память?

На самом деле не разбираясь в Java и особенно в отладке в Java, но получая дамп кучи в Jenkins с помощью Мониторинг и последующее декодирование в Eclipse с помощью MAT показывает, что общий объем используемой памяти составляет 169,4 МБ, тогда как при мониторинге Jenkins кажется, что память постоянно используется, и GC часто запускаются. -XmX — это 4G.

Почему я получаю только 169,4 МБ с MAT? Может быть потому, что перед созданием дампа Дженкинс выполняет GC? Если да, то могу ли я избежать этого, чтобы увидеть полный дамп памяти?


jenkins java memory dump heap-dump
person Zloj    schedule 25.09.2015    source источник
comment
Насколько я знаю, дамп вызовет gc раньше или, по крайней мере, MAT проигнорирует то, что в любом случае может быть gc'ed. Дженкинс, вероятно, будет загружать много данных во время задания, которое впоследствии имеет право на сборку мусора. Кстати, как вы запускаете дамп? Это встроенная функция Jenkins или вы отправляете команду JVM через JConsole или что-то подобное?   -  person Thomas    schedule 25.09.2015
comment
Дамп @Thomas можно запустить из плагина мониторинга. Есть кнопка - это все, что я могу сказать :) Это исходит из графического интерфейса Jenkins.   -  person Zloj    schedule 25.09.2015
comment
В этом случае может быть так, что плагин останавливает текущее задание или ждет его завершения (или просто загружено много данных, но они больше не нужны). - Я просто предполагаю, так как не знаю этого плагина. Но помимо этого, есть ли у вас проблемы с частыми GC?   -  person Thomas    schedule 25.09.2015
comment
@ Томас, я так не думаю. С памятью 4G GC выполняется примерно раз в 30 секунд и занимает 1 секунду. У меня есть проблемы с медленной загрузкой страниц / журналов консоли, но проблем с сетью нет, и журнал Jenkins ничего не говорит. Ошибок нигде нет, просто страницы загружаются медленно. Даже системная нагрузка на главном узле редко превышает 1 (используется 64-битный RHEL с 4 ядрами и 24-гигабайтной оперативной памятью вместе с другими 6 экземплярами Jenkins, которые используют меньше памяти).   -  person Zloj    schedule 25.09.2015
comment
@Thomas, как говорится, выполнение GC перед сбором дампа ... Разве это не немного неправильно? Как бы вы устраняли проблемы с памятью, если что-то резервирует слишком много памяти? Его просто очищают, чтобы никто никогда не узнал ... Попробую найти некоторые консольные команды для дампа кучи без GC.   -  person Zloj    schedule 25.09.2015
comment
Ну, обычно у вас возникают проблемы с памятью, для которых вам нужен дамп, когда память заполняется объектами, которые не могут быть проверены сборщиком мусора. Таким образом, вы обычно не хотите видеть объекты, которые в любом случае можно собрать.   -  person Thomas    schedule 25.09.2015
comment
Что говорится в отчете об используемой памяти без кучи? (теперь два Томаса)   -  person Thomas Weller    schedule 25.09.2015
comment
@ Томас Я не вижу этого ни в одном отчете MAT. Где я могу взглянуть на Используемую память без кучи? Файл имеет расширение .hprof, которое, как я полагаю, должно указывать на то, что он предназначен только для кучи. Я еще не сделал дамп без GC.   -  person Zloj    schedule 25.09.2015
comment
Я сделал дамп с помощью jmap. Также кажется, что он выполняет GC перед сбором дампа кучи, поэтому я не могу подробно изучить, что при этом больше всего использует память. Проблема №1 современного софта: никому нет дела до памяти, пока нет утечек и это не тостер с маленьким чипом или космическая станция. Спасибо за помощь, Томас №1 и №2 :)   -  person Zloj    schedule 25.09.2015
comment
Под используемой памятью без кучи я имел в виду эту графику. Это не будет частью дампа.   -  person Thomas Weller    schedule 25.09.2015
comment
@Thomas, он говорит, что использует строго от 1,5 до 3,5 G. Я предполагаю, что это немного ложь, поскольку, глядя на «используемую в настоящее время память» в мониторинге, я вижу, что он действует как узел эквалайзера, хотя и немного медленно - работает от 0 до чуть меньше max и снова падает.   -  person Zloj    schedule 25.09.2015
comment
Небольшое уточнение: не всегда уменьшение используемой памяти падает до 0. У меня нет времени вести подробную статистику по этому поводу, но непрерывный ПОЛНЫЙ GC здесь не проблема.   -  person Zloj    schedule 25.09.2015

Ответы (3)


arrow_upward
3
arrow_downward

Понимание памяти

Да, дамп кучи Java и дамп виртуальной памяти (называемый «аварийным дампом» или «дампом памяти» в Windows) — это разные вещи.

Дамп кучи Java содержит только память, относящуюся к Java, то есть место, где находятся объекты Java. Дамп кучи Java анализируется с помощью таких инструментов, как MAT (как вы упомянули) или Инструмент анализа кучи Java

Аварийный дамп Windows процесса (режим пользователя) содержит всю виртуальную память, где виртуальная память — это термин операционной системы, предоставляющей память. В Windows вся память выделяется через Виртуаллок.

Виртуальная память ОС будет включать кучу Java, поскольку Java может запрашивать память только у операционной системы.

Таким образом, при сравнении размеров памяти важно понимать, является ли инструмент специфичным для Java или общим для ОС.

В вашем случае Мониторинг выглядит как универсальный инструмент, поскольку он имеет дело со списком процессов и временем ЦП, а не с Java. С другой стороны, MAT, судя по описанию, явно является инструментом Java.

Различия в памяти

Итак, насколько размер кучи Java может отличаться от размера виртуальной памяти?

Много:

  1. Загруженные EXE/DLL учетные записи в виртуальную память, но не в кучу Java
  2. Память, используемая собственным кодом (например, через JNI), относится к виртуальной памяти, но не к куче Java.
  3. Память, запрошенная Java из ОС, но еще не используемая Java, определенно считается виртуальной памятью, но может быть указана как «свободная» с точки зрения Java.
person Thomas Weller    schedule 30.09.2015
comment
Спасибо за хороший ответ. Только одно небольшое исправление: в этом случае monitoring фактически отслеживает Jenkins JVM, а не операционную систему. - person Zloj; 30.09.2015

arrow_upward
1
arrow_downward

Судя по всему, инструменты, собирающие дамп кучи, выполняют GC для уменьшения размера дампа. Поскольку вещи, которые могут быть проверены GCed, не должны создавать OOM, это предназначено скорее для поиска утечек памяти, чем для устранения неполадок с использованием памяти.

person Zloj    schedule 27.09.2015

arrow_upward
0
arrow_downward

ВМ запрашивает виртуальную память для хранения различных данных. Затем виртуальная машина выделяет часть памяти для хранения переменных (то есть кучи), собственного кода (не кучи), резервирует часть памяти, которая еще не используется. В результате виртуальная память строго больше, чем куча. Нет никакой четкой корреляции между кучей и виртуальной памятью, учитывая, что вы можете написать простую бесконечную рекурсию (куча будет почти такой же большой, как виртуальная память) или загрузить большую dll в программу hello world (куча намного меньше, чем виртуальная память). ).

person sixtytrees    schedule 05.08.2016