Jboss java.lang.OutOfMemoryError: пространство кучи Java
время от времени jboss serwer выдает "Произошло необработанное исключение:
java.lang.OutOfMemoryError: Java heap space".
Не могли бы вы объяснить мне, как это работает?
Немного информации:
Jboss постоянно работает в автономном режиме в Windows.
С standalone.conf "JAVA_OPTS=-Xms1G -Xmx1G -XX:MaxPermSize=256M"
Разворачиваю файл войны ~ 50МБ, после тестов удаляю.
Какова возможная причина этого исключения пространства кучи Java?
Следует ли перезапускать сервер между следующими развертываниями?
Есть ли какая-нибудь команда для очистки места в куче?
Если я правильно понимаю, увеличение аргумента -Xmx не поможет. Это только задержит появление исключения. Верно?
заранее спасибо
Не думаю, что это утечка памяти. После перезапуска сервера все хорошо. Через некоторое время исключение снова возникает в совершенно другой сборке. Более того, когда я запускаю jboss serwer, он потребляет около 560 МБ памяти (из диспетчера задач), когда происходит exceptoin, занимаемая память этим процессом Java составляет более 1,5 ГБ
@ TomekKoźlak другая сборка одного и того же приложения после перезапуска не является индикатором отсутствия утечки памяти. то есть это все еще может быть утечка памяти.
Эта ссылка может быть полезной: cubrid.org/blog/… Это может быть утечка памяти, а может и нет. Что делает приложение? Кэширует много данных? Это размещение больших объектов? Как много? Размещает много мелких объектов? Как часто предметы выживают в новой коллекции? Какой дистрибутив Java вы используете? Вы используете 32-битную или 64-битную версию? Посмотрите: dzone.com/articles/…
@JasonArmstrong - я бы описал приложение, которое кэширует много данных таким образом, что сборщик мусора не может освободить их, когда это необходимо, как утечку памяти.
@StephenC - потенциально плохой выбор слов. Некоторым приложениям действительно требуется много памяти, некоторые из них кэшируются, некоторые из них - это большие объекты, некоторые из них - это множество мелких объектов, которые могут / не могут нуждаться в хранении. Здесь есть вероятность, что это может быть проблема с мешком весом 5 фунтов. OP не узнает, пока не профилирует это, но возможно, ему просто потребуется больше памяти.
@JasonArmstrong - Да. Но если компонент кеширования реализован правильно, он не будет причиной ошибок OOME. GC должен инициировать очистку кеша до того, как произойдет OOME. Или, другими словами, кеш, который не отвечает на сборщик мусора, по сути, является утечкой памяти.
Ответы 3
Увеличьте значение переменной MaxPermSize и убедитесь, что она работает.
JAVA_OPTS=-Xms1G -Xmx1G -XX:MaxPermSize=512M
Я предполагаю, что это решение не поможет из-за этого предупреждения в начале журналов при запуске сервера: Предупреждение виртуальной машины 64-разрядного сервера Java HotSpot (TM): игнорирование параметра MaxPermSize = 256M; поддержка была удалена в 8.0
вы можете попробовать это решить эту проблему. В JBoss EAP 6.4 щелкните правой кнопкой мыши на сервере и откройте конфигурацию запуска в параметре виртуальной машины, вы найдете {-Dprogram.name = JBossTools: jboss-eap "-server -Xms1024m -Xmx1024m -XX: MaxPermSize = 256m}, обновите его до {- Dprogram.name = JBossTools: JBoss 6.4 "-server -Xms512m -Xmx512m} это решит вашу проблему. Ссылка: stackoverflow.com/questions/22634644/…
What is possible cause of this Java heap space exception?
На первый взгляд объяснение простое. JVM исчерпал объем кучи, и сборщик мусора не может освободить достаточно места для продолжения.
Но что заставило JVM перейти в это состояние?
Есть несколько возможных объяснений, но в основном они делятся на три класса:
В вашем приложении утечка памяти.
Повторные развертывания вызывают утечку памяти.
Утечек памяти нет, но иногда ваше приложение получает запрос, которому просто требуется слишком много памяти.
Should I restart server between following deploys?
Этот мая поможет, если развертывания вызывают утечки. Если нет, то не будет.
Is there any command to clean heap space?
Нет команды, которая сделает это. JVM уже запустит "полный" сборщик мусора перед тем, как выбросить OOME.
If I understand corectly increasing of -Xmx argument will not help. It will only delay the appearance of the exception. Right?
Это зависит от. Если основная причина - №3 выше, то увеличение размера кучи может решить проблему. Но если основная причина - №1 или №2, то изменение размера кучи (в лучшем случае) заставит JVM дольше работать между сбоями.
Я рекомендую для начала рассматривать это как «нормальную» (причину №1) утечку памяти и использовать профилировщик памяти для выявления и исправления утечек, которые могут возникать со временем.
Если / когда вы можете окончательно устранить причину № 1, рассмотрите другие.
Сегодня я увидел еще одно исключение: «java.lang.OutOfMemoryError: превышен предел накладных расходов сборщика мусора»
По сути, это та же проблема.
Я полностью согласен с ответом Стивен С, я просто хочу показать вам возможный способ его анализа.
Минимальный инструмент для мониторинга памяти - jstat, идущий в комплекте с JDK.
После запуска JBoss вы можете начать мониторинг памяти и GC с помощью
jstat -gc <JBOSS_PID> 2s
Затем вывод можно загрузить, например, в Excel.
Теперь, когда вы узнаете, что с памятью происходит что-то странное, сделайте дамп кучи:
jcmd <JBOSS_PID> GC.heap_dump <filename>
jcmd также поставляется с JDK.
Затем вы можете загрузить дамп кучи в МАТ и проанализировать его. Работа с MAT требует некоторой практики и терпения. Еще у них хороший Руководство. Вы также можете сравнить дампы кучи в MAT.
Я также предлагаю вам добавить XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=<path>" в ваш JAVA_OPTS.
У вас может быть утечка памяти в вашем коде. Увеличение размера просто задержит OOM ... Попробуйте использовать некоторые инструменты профилирования, чтобы увидеть, что пожирает вашу память и не освобождает ее.