Jboss java.lang.OutOfMemoryError: пространство кучи Java - PullRequest
Новая
       8

Jboss java.lang.OutOfMemoryError: пространство кучи Java

0 голосов
/ 06 ноября 2018

время от времени выбрасывает jboss serwer "Произошло необработанное исключение:

java.lang.OutOfMemoryError: Java heap space ".

Не могли бы вы объяснить, как это работает?

Немного информации: Jboss все время работает в автономном режиме в Windows. От standalone.conf "JAVA_OPTS=-Xms1G -Xmx1G -XX:MaxPermSize=256M" Я развернул ~ 50MB военный файл, после тестирования я его удалил

Какова возможная причина этого исключения пространства кучи Java? Должен ли я перезапустить сервер между следующими развертываниями? Есть ли команда для очистки кучи? Если я понимаю, что увеличение аргумента -Xmx не поможет. Это только задержит появление исключения. Правильно?

Заранее спасибо

Ответы [ 3 ]

0 голосов
/ 06 ноября 2018

Какова возможная причина этого исключения пространства кучи Java?

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

Но что заставило JVM войти в это состояние?

Есть несколько возможных объяснений, но они в основном делятся на три класса:

  1. Ваше приложение имеет утечку памяти.

  2. Повторные развертывания вызывают утечку памяти.

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

Должен ли я перезапускать сервер между следующими развертываниями?

Это может помочь, если развертывания вызывают утечки. Если нет, то не будет.

Есть ли какая-нибудь команда для очистки кучи?

Нет команды, которая сделает это. JVM уже запустит «полный» сборщик мусора, прежде чем выдать OOME.

Если я правильно понимаю, увеличение аргумента -Xmx не поможет. Это только задержит появление исключения. Правильно?

Это зависит. Если основной причиной является № 3 выше, то увеличение размера кучи может решить проблему. Но если основной причиной является # 1 или # 2, то настройка размера кучи (в лучшем случае) заставит JVM дольше выживать между сбоями.

Я рекомендую начать с трактовки этого явления как «нормальной» (причина № 1) утечки памяти и использовать профилировщик памяти для выявления и устранения утечек, которые могут возникнуть со временем.

Если / когда вы можете окончательно устранить причину # 1, рассмотрите другие.

0 голосов
/ 07 ноября 2018

Я абсолютно согласен с ответом Стивеном C , я просто хочу показать вам возможный способ его анализа.

Минимальный инструмент для мониторинга памяти - jstat и поставляется с JDK. После запуска JBoss вы можете начать мониторинг памяти и GC с помощью

jstat -gc <JBOSS_PID> 2s

Выход может быть загружен, например, в Excel.

Теперь, когда вы узнаете, что с памятью происходит что-то странное, возьмите дамп кучи:

jcmd <JBOSS_PID> GC.heap_dump <filename>

jcmd также поставляется с JDK.

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

Я также предлагаю добавить XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=<path>" к вашему JAVA_OPTS.

0 голосов
/ 06 ноября 2018

Увеличьте переменную MaxPermSize и проверьте, будет ли она работать.

JAVA_OPTS = -Xms1G -Xmx1G -XX: MaxPermSize = 512M

...