0

起動時に OOM エラーをスローする weblogic サーバーがあります。そのため、アプリケーションが適切に動作していません。

ヒープダンプを収集しました [下のスナップショット] が、出力がよくわかりません。

イメージスナップ: http://img51.imageshack.us/img51/7470/heapanalysis.jpg

OOM エラーが発生する理由を理解していただけますか? 以下は JVM 引数です。

 Starting WLS with line:
 /java -server   -Xms1536m -Xmx1536m -XX:PermSize=512m -XX:MaxPermSize=512m -XX:NewSize=512m -XX:MaxNewSize=512m -XX:SurvivorRatio=6 -Xnoclassgc -XX:+DisableExplicitGC -verbose:gc -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:+CMSIncrementalMode -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+HeapDumpOnOutOfMemoryError   

以下は、ログに表示されるエラーです。

> java.lang.OutOfMemoryError: Java heap space Dumping heap to
> java_pid16660.hprof ...
> 115.814: [GC [1 CMS-initial-mark: 743854K(1048576K)] 743854K(1507328K), 0.0050472 secs]
> 115.819: [CMS-concurrent-mark-start] Heap dump file created [778142756 bytes in 3.935 secs] <Jan 20, 2013 10:56:05 PM PST> <Critical>
> <WorkManager> <BEA-002911> <WorkManager weblogic.kernel.System failed
> to schedule a request due to java.lang.OutOfMemoryError: Java heap 
> space java.lang.OutOfMemoryError: Java heap space
> > <Jan 20, 2013 10:56:05 PM PST> <Critical> <WorkManager> <BEA-002911> <WorkManager weblogic.kernel.System failed to schedule a request due
> to java.lang.ArrayIndexOutOfBoundsExcept ion: 26214404
> java.lang.ArrayIndexOutOfBoundsException: 26214404
>         at weblogic.work.CalendarQueue.add(CalendarQueue.java:39)
>         at weblogic.work.RequestManager.addToPriorityQueue(RequestManager.java:263)
>         at weblogic.work.RequestManager.executeIt(RequestManager.java:235)
>         at weblogic.work.ServerWorkManagerImpl.schedule(ServerWorkManagerImpl.java:142)
>         at weblogic.corba.cos.transactions.RecoveryRegistrar.run(RecoveryRegistrar.java:47)
>         Truncated. see log file for complete stacktrace
4

2 に答える 2

0

私は Eclipse メモリ アナライザー ツールに慣れているので、Eclipse MAT ツールを使用して HPROF ファイルを分析する方法について回答します。

HPROF ファイルを Eclipse で開いて解析を終了すると、原因が (MAT にとって) より単純またはより明白である場合、「リーク容疑者レポート」で犯人スレッド/Web リクエストが示されます。

運が悪い場合は、次のようにします。

  1. ヒストグラムオプションをクリックします
  2. 右側の Retained Heap フィールドに基づいてテーブルを並べ替える

  3. ヒストグラム ビューには、メモリが消費されたアクティブなオブジェクトのテーブルが表示されます。通常は、HashMaps、Lists などの低レベルクラスです。

  4. あなたの目的は、これらのトップコンシューマーから、アプリケーションコードの一部であり、メモリホグのイニシエーターであると認識しているクラスまで、ツリーの上位にあるクラスを見つけることです。Web アプリの場合、すべてを開始した特定のユーザー HTTP 要求に到達する可能性があります。
  5. 最上位のクラス名を選択し、右クリックして [GC ルートへの最短パス - > ファントム、ソフト、弱い参照を除外] を選択します。
  6. 結果のテーブルには、メモリ不足の原因となったスレッドを開始した最上位の Java クラスまたは Http リクエストが一覧表示されます。このリストにより、誤動作の原因を分析できる狭いフィールドが提供されます。

注: MAT はそれ自体かなりメモリを集中的に使用するため、サイズが白黒 5 ~ 8 GB の HPROF ファイルを解析するには、少なくとも 8 GB の RAM が必要であり、ファイルを通じて MAT ツールの初期化パラメータを設定する必要があり ます、-Xmx6144mに言ってください

于 2014-09-03T15:10:51.763 に答える
0

Visual VMをダウンロードし、すべてのプラグインをインストールして、WebLogic を実行するときに PID にアタッチすることをお勧めします。

あなたの HPROF は読みにくいですが、それらがバイトである場合、ここでは問題はありません。

于 2013-01-21T12:33:38.060 に答える