2016-03-04 3 views
2

Я хочу выяснить, почему использование кучи JVM на узле Elasticsearch остается стабильно выше 80%. Для этого я беру кучу отвалов, запустивКак свалить кучу в окнах с минимальным временем простоя?

jmap.exe -heap:format=b 5348 

(5348 - это идентификатор процесса). Затем я смогу проанализировать дамп с помощью VisualVM.

Проблема заключается в том, что jmap останавливает JVM при съемке дампа, поэтому узел в основном отключается в течение примерно 5 минут.

This article предлагает более быстрый подход, основанный на использовании coredump с gdb в Linux. Я уже пробовал WinDbg, который создал основной дамп, но я не мог использовать его в VisualVM.

Есть ли аналогичный подход для Windows? Как можно взять кучи кучи в считанные секунды, а не минуты?

+0

Я бы удостоверился, что: а) вы используете двоичный режим; б) ваша куча как можно меньше, чтобы начать, например. минимизируйте размер кучи, запускайте полный GC перед съемкой. –

+0

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

+0

Сброс кучи не будет дешевым, так как ему придется остановить JVM, чтобы получить все данные в последовательном снимке. –

ответ

5

После того, как вы приняли CoreDump по WinDbg, вам нужно извлечь дамп кучи из него, запустив

jmap -heap:format=b "C:\Program Files\Java\...\bin\java.exe" core.mdmp 

Это может быть сделано в автономном режиме; не требуется взаимодействие с запущенным Java-процессом. Затем вы сможете открыть сгенерированный heap.bin в VisualVM.


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

jmap -histo <PID> 

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

+0

Спасибо @apangin, оба решения работают отлично! –

Смежные вопросы