Исключение Java OutOfMemory: ошибка mmap при загрузке zip-файла

я запускаю свое приложение на production env (rhel 5.2 x64, oracle jre 1.7_05, tomcat 7.0.28) с аргументами JVM:

-Xms8192m -Xmx8192m -XX:MaxPermSize=1024m 
-Doracle.net.tns_admin=/var/ora_net -XX:ReservedCodeCacheSize=512m -XX:+AggressiveOpts -XX:+UseFastAccessorMethods 
-XX:+UseStringCache -XX:+OptimizeStringConcat -XX:+UseCompressedOops -XX:+UseG1GC -Dcom.sun.management.jmxremote 
-Dcom.sun.management.jmxremote.port=9026 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false

через несколько раз у меня есть трассировка стека:

Java HotSpot(TM) 64-Bit Server VM warning: Attempt to deallocate stack guard pages failed.
Java HotSpot(TM) 64-Bit Server VM warning: Attempt to allocate stack guard pages failed.
mmap failed for CEN and END part of zip file
[...]
Caused by: java.lang.OutOfMemoryError: null
    at java.util.zip.ZipFile.$$YJP$$open(Native Method) ~[na:1.7.0_05]
    at java.util.zip.ZipFile.open(Unknown Source) ~[na:1.7.0_05]
    at java.util.zip.ZipFile.<init>(Unknown Source) ~[na:1.7.0_05]
    at java.util.zip.ZipFile.<init>(Unknown Source) ~[na:1.7.0_05]
    at java.util.jar.JarFile.<init>(Unknown Source) ~[na:1.7.0_05]
    at java.util.jar.JarFile.<init>(Unknown Source) ~[na:1.7.0_05]
    at sun.net.www.protocol.jar.URLJarFile.<init>(Unknown Source) ~[na:1.7.0_05]
    at sun.net.www.protocol.jar.URLJarFile.getJarFile(Unknown Source) ~[na:1.7.0_05]
    at sun.net.www.protocol.jar.JarFileFactory.get(Unknown Source) ~[na:1.7.0_05]
    at sun.net.www.protocol.jar.JarURLConnection.connect(Unknown Source) ~[na:1.7.0_05]
    at sun.net.www.protocol.jar.JarURLConnection.getInputStream(Unknown Source) ~[na:1.7.0_05]
    at java.net.URL.openStream(Unknown Source) ~[na:1.7.0_05]
    at org.apache.catalina.loader.WebappClassLoader.findLoadedResource(WebappClassLoader.java:3279) ~[na:na]
    at org.apache.catalina.loader.WebappClassLoader.getResourceAsStream(WebappClassLoader.java:1478) ~[na:na]
    at org.apache.http.util.VersionInfo.loadVersionInfo(VersionInfo.java:242) ~[httpcore-4.2.jar:4.2]
    at org.apache.http.impl.client.DefaultHttpClient.setDefaultHttpParams(DefaultHttpClient.java:180) ~[httpclient-4.2.jar:4.2]
    at org.apache.http.impl.client.DefaultHttpClient.createHttpParams(DefaultHttpClient.java:158) ~[httpclient-4.2.jar:4.2]
    at org.apache.http.impl.client.AbstractHttpClient.getParams(AbstractHttpClient.java:448) ~[httpclient-4.2.jar:4.2]

глядя на мой профилировщик-everthing в порядке (куча и не куча памяти используется для 10%), и я понятия не имею, где проблема.

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

редактировать:

новый вывод в лог-файл:

Java HotSpot(TM) 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled.
Java HotSpot(TM) 64-Bit Server VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize=
Code Cache  [0x00002aaaab790000, 0x00002aaaad240000, 0x00002aaacb790000)
 total_blobs=4223 nmethods=3457 adapters=707 free_code_cache=497085Kb largest_free_block=508887936

но у меня достаточно памяти:http://i.stack.imgur.com/K8VMx.jpg

ответ: Проблема в версии java. Он описал здесь:https://forums.oracle.com/forums/thread.jspa?messageID=10369413

11
java java-7 mmap out-of-memory

4 ответов

Я видел эту ошибку раньше, когда заканчивались ресурсы, такие как исчерпание пространства подкачки или запуск разрешенного сопоставления памяти. Взгляните на sudo cat /proc/$PID/maps | wc -l по сравнению с cat /proc/sys/vm/max_map_count

см. комментарии ниже.

Я тоже предложил ....

вы, похоже, столкнулись с ошибкой с YourKit. Какую версию вы используете?

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

-mx8g -XX:MaxPermSize=1g -Doracle.net.tns_admin=/var/ora_net 
-XX:ReservedCodeCacheSize=512m -XX:+UseG1GC -Dcom.sun.management.jmxremote.port=9026

Я бы попробовал упасть -XX:+UseG1GC а также это относительно новый коллектор и не должен изменять ваши результаты.

4

Не уверен, что изменилось в Java 1.7, как я помню из Java 1.6, мы используем параметры Xms, как показано ниже.

  -Xms=512m -Xmx=512m
0

попробуйте эти варианты

-Xrunhprof:heap=all,depth=12,cutoff=0

это создаст файл дампа в корне приложения. Позже вы можете проанализировать с HP Jmeter. Это даст мгновенный снимок того, что случилось с вашими 8Gigs памяти. Вы можете увидеть инструкции HP JMeter здесь.

также мудро выбрал параметры Xrunhprof. Вышеупомянутый вариант, который я упомянул, будет генерировать огромный файл дампа. Из руководств вы можете найти подходящие варианты.

0

некоторые пункты оригинальная статья в блоге, это объясняет, как работает java jar / zip:

ошибка OOM запускается во время собственного вызова (ZipFile.open (Native Method)) из Java JDK ZipFile загрузить файл приложения EAR. Эта собственная операция JVM требует наличия собственной памяти и виртуального адресного пространства для выполнения операции загрузки. На данный момент вывод заключался в том, что у нашей Java VM 1.5 заканчивалась собственная память / виртуальное адресное пространство во время развертывания.

Sun Java VM родная память и файлы MMAP

при использовании JDK 1.4 / 1.5 любой файл JAR / ZIP, загруженный Java VM, полностью сопоставляется в адресное пространство. Это означает, что чем больше файлов EAR / JAR вы загружаете в одну JVM, тем выше собственный объем памяти вашего процесса Java.

Это также означает, что чем выше ваша куча Java и пространство PermGen; нижняя память остается для ваших собственных пространств памяти, таких как файлы C-Heap и MMAP, которые определенно могут быть проблемой, если вы развертываете слишком много отдельных приложений (файлов EAR) в один 32-разрядный процесс Java.

обратите внимание, что Sun придумал улучшения в JDK 1.6 (Mustang) и изменил поведение так, что Центральный каталог jar-файла по-прежнему отображается, но сами записи читаются отдельно; уменьшая потребность в собственной памяти.

Я предлагаю вы просматриваете ссылку Sun Bug Id ниже для более подробной информации о таком ограничении JDK 1.4 / 1.5. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6280693

0