JavaのOutOfMemory例外：ロードzipファイル上のmmapエラー

Question

私は、生産のenvに私のアプリを実行します（RHEL 5.2のx64、オラクルJRE 1.7_05、Tomcatの7.0.28）JVM引数を持つ：いくつかの時間の後

​​

Iそのようになったスタックトレースを」VEの：

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がOK（ヒープおよび非ヒープメモリは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

Answer 1

私は、このようなスワップ領域の不足または許可メモリマッピングが不足などのリソースが不足したときに前にこれらのエラーを見てきました。 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をドロップしようとするだろうし、あなたの結果を変更しないでください。

Answer 2

私はJava 1.6から覚えているように、以下のようにXmsオプションを使用しています。

-Xms=512m -Xmx=512m 

Answer 3

これは、アプリケーションのルートでダンプファイルを生成します

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

これらのオプションを試してみてください。後でHP Jmeterと解析することができます。これはあなたの8GIGメモリに起こったことのスナップショットを与えるでしょう。 HP JMeterのマニュアルhereが表示されます。

また、Xrunhprofオプションを賢明に選択しました。私が述べた上記のオプションは、巨大なダンプファイルを生成します。マニュアルから適切なオプションを見つけることができます。

Answer 4

original blog articleのいくつかの段落で、これはJavaのjarファイル/ジッパーがどのように機能するかを説明します

OOMエラーがロードするためのJava JDK ZIPファイルからネイティブコール（ZipFile.open（ネイティブメソッド））の間にトリガされますアプリケーションのEARファイル。このネイティブJVM操作では、ロード操作を実行するために使用可能なネイティブメモリーと仮想アドレス空間が必要です。この時点での結論は、展開時にJava VM 1.5がネイティブのメモリ/仮想アドレス空間を使い果たしていたことです。

のSun Java VMのネイティブメモリとMMAPファイル

JDK 1.4/1.5を使用すると、Java VMによってロードされたすべてのJAR/ZIPファイルが完全にアドレス空間にマッピングされます。つまり、1つのJVMにロードするEAR/JARファイルが多いほど、Javaプロセスのネイティブなメモリフットプリントが高くなります。

これは、Javaヒープ領域とPermGen領域が高くなることを意味します。 1つの32ビットJavaプロセスにあまりにも多くの別個のアプリケーション（EARファイル）を展開している場合は、CヒープやMMAPファイルなどのネイティブメモリスペースにはより低いメモリが問題になります。

SunはJDK 1.6（Mustang）の改良を思いつき、JARファイルの中央ディレクトリがまだマップされているが、エントリ自体は別々に読み込まれるように動作を変更しました。ネイティブのメモリ要件を削減します。

このようなJDK 1.4/1.5の制限の詳細については、下記のSun Bug Idリンクを参照することをお勧めします。 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6280693