Как долго можно выполнять вычисление сохраненных размеров в визуальной виртуальной машине для кучи размером 1 ГБ?

У меня есть дамп кучи объемом 1 ГБ из процесса Java, в котором не хватило места в куче. Я загрузил кучу в jvisualm, который поставляется с дистрибутивом java6. Я запустил процесс «вычислить сохраненные размеры» около 16 часов назад, и он все еще работает. Сколько времени должно пройти, чтобы вычислить сохраненные размеры для 20 основных объектов в куче размером 1 ГБ? Должен ли я ожидать, что это когда-нибудь закончится?


java memory visualvm heap
person Joe    schedule 29.11.2011    source источник
comment
Я понятия не имею, о чем вы говорите (у меня мало опыта работы с Java), но моя логика подсказывает мне, что если вы не используете это на 1 ГГц с системой 1 ГБ ОЗУ (или меньше), 16 часов waaay перебор...   -  person    schedule 29.11.2011
comment
Просто для любопытства, он закончился? Как долго это займет? Если он не завершился, успешно ли завершился второй запуск?   -  person uhm    schedule 02.12.2011
comment
Это так и не закончилось. В итоге я скачал пробную версию YourKit, и тот же процесс завершился примерно за 20 минут.   -  person Joe    schedule 03.12.2011
comment
Для справки: дамп кучи размером 14 ГБ (.bin) занял около 12 часов на MacBook Pro с 16 ГБ ОЗУ. VisualVM получил 10G с -J-Xmx10g.   -  person Christoph    schedule 19.09.2020

Ответы (2)


arrow_upward
9
arrow_downward

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

Чтобы открыть журнал, я использовал следующие шаги:

  • Нажмите Справка
  • Нажмите О программе
  • Щелкните файл журнала.

Это показало мне внизу журнала:

SEVERE [org.openide.util.RequestProcessor]
java.lang.OutOfMemoryError: GC overhead limit exceeded
    at java.util.HashMap.newNode(HashMap.java:1734)
    at java.util.HashMap.putVal(HashMap.java:630)
    at java.util.HashMap.put(HashMap.java:611)
    at java.util.HashSet.add(HashSet.java:219)
    at org.netbeans.lib.profiler.heap.DominatorTree.intersect(DominatorTree.java:279)
    at org.netbeans.lib.profiler.heap.DominatorTree.computeOneLevel(DominatorTree.java:114)
    at org.netbeans.lib.profiler.heap.DominatorTree.computeDominators(DominatorTree.java:64)
    at org.netbeans.lib.profiler.heap.HprofHeap.computeRetainedSize(HprofHeap.java:537)
    at org.netbeans.lib.profiler.heap.HprofHeap.computeRetainedSizeByClass(HprofHeap.java:594)
    at org.netbeans.lib.profiler.heap.ClassDump.getRetainedSizeByClass(ClassDump.java:102)
    at org.netbeans.modules.profiler.heapwalk.HeapFragmentWalker.computeRetainedSizes(HeapFragmentWalker.java:100)
    at org.netbeans.modules.profiler.heapwalk.ClassPresenterPanel$1$1.run(ClassPresenterPanel.java:187)
    at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1393)
[catch] at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:2003)

По умолчанию мой 64-битный размер кучи Java VM будет ограничен 25% памяти моего компьютера (или даже гораздо меньшим встроенным пределом VisualVM). Чтобы решить эту проблему для моей следующей попытки, я попытаюсь снова запустить VisualVM следующим образом:

jvisualvm.exe -J-Xmx16g

После этого журнал показывает при запуске:

Heap memory usage: initial 24,0MB maximum 14563,6MB
person JohannesB    schedule 29.11.2016
comment
Я обнаружил, что jvisualvm игнорирует флаг командной строки mx из командной строки, поскольку он уже извлекает значение по умолчанию -Xmx256m из %JDK_HOME%\lib\visualvm\etc\visualvm.conf. См. stackoverflow.com /вопросы/9570921/ - person Barry Pitman; 19.07.2017

arrow_upward
2
arrow_downward

У меня была куча размером 600 МБ, которой потребовалось всего 900 минут процессорного времени для вычисления сохраненных размеров. Это 15 часов. Я бы предположил, что это очень связано с тем, что находится в куче, поэтому я не буду экстраполировать на вашу кучу (также вы указали, что это не закончилось;), но это еще одна точка данных.

person Rob I    schedule 17.01.2012