11

私は、JVM引数を使用して本番環境（rhel 5.2 x64、oracle jre 1.7_05、tomcat 7.0.28）でアプリを実行します。

-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]

私のプロファイラーを見ると、すべて問題がなく（ヒープメモリと非ヒープメモリが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

4

4 に答える 4

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これは比較的新しいコレクターであり、結果を変更するべきではないので、ドロップしてみます。

于 2012-10-10T08:50:41.970 に答える
0

Java 1.6から覚えているように、Java 1.7で何が変更されたかはわかりませんが、以下のようにXmsオプションを使用しています。

  -Xms=512m -Xmx=512m
于 2012-10-10T08:45:36.890 に答える
0

これらのオプションを試してください

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

これにより、アプリケーションルートにダンプファイルが生成されます。後でHPJmeterで分析できます。これにより、8ギガのメモリに何が起こったかのスナップショットが得られます。HPJMeterのマニュアルはこちらでご覧いただけます。

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

于 2012-10-10T08:59:28.993 に答える
0

元のブログ記事のいくつかの段落で、これはjava jar/zipがどのように機能するかを説明しています。

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

SunJavaVMネイティブメモリとMMAPファイル

JDK 1.4 / 1.5を使用する場合、JavaVMによってロードされたJAR/ZIPファイルはすべてアドレス空間に完全にマップされます。これは、単一のJVMにロードするEAR / JARファイルが多いほど、Javaプロセスのネイティブメモリフットプリントが高くなることを意味します。

これは、JavaヒープとPermGenスペースが高いことも意味します。低い方のメモリは、CヒープやMMAPファイルなどのネイティブメモリスペースに残されます。これは、単一の32ビットJavaプロセスに多数の個別のアプリケーション（EARファイル）をデプロイする場合に間違いなく問題になる可能性があります。

SunはJDK1.6（Mustang）の改善を考え出し、JARファイルの中央ディレクトリが引き続きマップされるように動作を変更しましたが、エントリ自体は個別に読み取られることに注意してください。ネイティブメモリ要件を削減します。

このようなJDK1.4/ 1.5の制限の詳細については、以下のSunBugIdリンクを確認することをお勧めします。 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6280693

于 2013-04-13T02:49:49.867 に答える