Как бороться с JVM OutOfMemoryError в Linux? - PullRequest
Новая
       36

Как бороться с JVM OutOfMemoryError в Linux?

0 голосов
/ 14 марта 2012

Redhat Enterprise Linux 5.4 32-битная + Sun HotSpot JVM 6u5 32-битная + настройки JVM -Xms1536m -Xmx2048m -XX:PermSize=128m -XX:MaxPermSize=512m.

JVM аварийно завершает работу со следующими ошибками:

java.lang.OutOfMemoryError: запрошено 828752 байта для Chunk :: new.Вне пространства подкачки?Внутренняя ошибка (alloc.cpp: 218), pid = 21557, tid = 329534352 Ошибка: Chunk :: new

java.lang.OutOfMemoryError: запрошено 383504 байта для GrET в / BUILD_AREA / jdk6_05 / hotspot / src /доля / VM / утилиты / growableArray.cpp.Вне пространства подкачки?Внутренняя ошибка (alloc.inline.hpp: 42), pid = 16927, tid = 334281616 Ошибка: GrET в /BUILD_AREA/jdk6_05/hotspot/src/share/vm/utilities/growableArray.cpp

java.lang.OutOfMemoryError: запрошено 256000 байт для GrET в /BUILD_AREA/jdk6_05/hotspot/src/share/vm/utilities/growableArray.cpp.Вне пространства подкачки?Внутренняя ошибка (alloc.inline.hpp: 42), pid = 16863, tid = 334216080 Ошибка: GrET в /BUILD_AREA/jdk6_05/hotspot/src/share/vm/utilities/growableArray.cpp ..........

Это может быть утечка памяти ядра C / C ++ самой JVM, использование памяти C / C ++, достигшее критического значения JVM, или недостаточно места подкачки платформы.

Какиметь дело с самой утечкой памяти ядра C / C ++ в JVM?
Valgrind v3.7 не может работать с горячей точкой JVM 6u5.

Ответы [ 2 ]

0 голосов
/ 21 марта 2013

Это ясно говорит о том, что ваша JVM не может выделить дополнительную память.Доступная (физическая) память равна 0, поэтому ваша система использует своп.Затем, в какой-то момент, подкачка заполнится страницами подкачки памяти и, следовательно, дальнейший запрос памяти (alloc) не будет выполнен.

Проверьте использование вашего свопа с помощью 

$ swapon -s 
Filename                Type        Size    Used    Priority
/dev/xvda2              partition   8386556 99312   -1

. Вы можете увеличитьразмер свопа в любое время. Смотрите эту ссылку

0 голосов
/ 12 апреля 2012

Сбой JVM здесь просто обманчив. Проблема в том, что у процесса заканчивается адресное пространство. Ваш «-Xmx2048m» просто слишком велик для текущей доступной виртуальной памяти и / или конкретной 32-битной операционной системы в целом.

В 32-битной Windows любой процесс может адресовать до ~ 1,6 ГБ ОЗУ. Другие ОС зависит. Linux должен быть в состоянии использовать ~ 3 ГБ макс.

Помимо размера кучи вашего объекта (-Xmx) JVM требуется дополнительная оперативная память для стека, управления объектами, структурами gc и т. Д. На практике это приводит к тому, что в 32-разрядных системах Windows максимальный размер кучи составляет около 1100 МБ.

Подробнее об ограничении размера памяти процесса см., Например, в этом блоге: https://sinewalker.wordpress.com/2007/03/04/32-bit-windows-and-jvm-virtual-memory-limit

...