0

最近、Solaris SunOS 5.10 から Redhat Linux VM へのサーバー移行を実行しました。JVM は 1.5.0_22 (32 ビット) から 1.6.0_06 (64 ビット) にアップグレードされましたが、それ以降、OutOfMemory エラーが頻繁に発生します。64 ビット JVM には 30 ~ 50% 多いヒープが必要であることを調査したため、ヒープ サイズを 1200MB から 2048MB に増やして試してみました。ただし、サーバーを数日間実行した後でも、いくつかの OOME が発生することが確認されました。

GC ログを確認したところ、サーバーが数日間起動した後にフル GC が頻繁に発生し、フル GC ごとに少量のメモリしか解放されず、フル GC が頻繁に行われるとアプリケーションの速度が低下することがわかりました。

GC ログの抜粋を見るとわかるように、PSOldGen ではほとんどメモリが解放されていません。

205023.895: [Full GC [PSYoungGen: 225919K->157256K(240960K)] [PSOldGen: 1841151K->1841151K(1841152K)] 2067071K->1998408K(2082112K) [PSPermGen: 108720K->108720K(109056K)], 6.2785770 secs] [Times: user=6.23 sys=0.01, real=6.28 secs] 
Heap after GC invocations=1638 (full 251):
 PSYoungGen      total 240960K, used 157256K [0x00002aab2e800000, 0x00002aab3e200000, 0x00002aab3e200000)
  eden space 225920K, 69% used [0x00002aab2e800000,0x00002aab38192208,0x00002aab3c4a0000)
  from space 15040K, 0% used [0x00002aab3d350000,0x00002aab3d350000,0x00002aab3e200000)
  to   space 15040K, 0% used [0x00002aab3c4a0000,0x00002aab3c4a0000,0x00002aab3d350000)
 PSOldGen        total 1841152K, used 1841151K [0x00002aaabe200000, 0x00002aab2e800000, 0x00002aab2e800000)
  object space 1841152K, 99% used [0x00002aaabe200000,0x00002aab2e7fffc8,0x00002aab2e800000)
 PSPermGen       total 109056K, used 108720K [0x00002aaaae200000, 0x00002aaab4c80000, 0x00002aaabe200000)
  object space 109056K, 99% used [0x00002aaaae200000,0x00002aaab4c2c3f8,0x00002aaab4c80000)
}  

これは、24 時間以内の 1 つの OC4J インスタンスのヒープ使用パターンです。これは私にとって非常に奇妙です。ジグザグのパスではなく、ランダムなパターンを示しています。 ここに画像の説明を入力

どうすればよいか分かりますか?

サーバー構成:

Red Hat Enterprise Linux Server release 5.7 (Tikanga) 2.6.18 274.el5 (64-bit)
CPU : 8, 16GB RAM
JVM version : Java(TM) SE Runtime Environment (build 1.6.0_06-b02)
Application server : OC4J 10.1.3.5

JVM 起動引数:

//Old confing
-server -Xms1200M -Xmx1200M -XX:MaxPermSize=64M -XX:+PrintHeapAtGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xnoclassgc -verbose:gc -XX:NewSize=250M -XX:MaxNewSize=250M -XX:SurvivorRatio=15 -Xconcurrentio -Xss128k

//New config
-server -Xms2048M -Xmx2048M -XX:MaxPermSize=256M -XX:+PrintHeapAtGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xnoclassgc -verbose:gc -XX:NewSize=250M -XX:MaxNewSize=250M -XX:SurvivorRatio=15 -Xconcurrentio -Xss128k
4

1 に答える 1

0

これは、アプリケーションのメモリ リークか、Java メモリ管理のバグです。

1.6.0_06 リリース以降、メモリ管理とガベージ コレクションに関する多数のバグ修正が行われました。たとえば、次の 2 つです。

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6676016 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6824570

したがって、次のことを試してください。

  1. 新しい Java 1.6.0 ビルドにアップグレードします。(それが不可能な場合は、GC 戦略の設定を (たとえば) 並列から並行に変更して、Java の潜在的なバグを回避できるかどうかを確認できます。
  2. ヒープダンプ (jmap) を使用してアプリケーションのメモリ リークをトラブルシューティングし、何がヒープを占有しているかを確認します。
于 2013-08-23T08:29:01.420 に答える