10

私のサーバーアプリケーションが高負荷でクラッシュしているという苦情があります。
で実行されているWebアプリですTomcat 5。
スレッドダンプが表示され、OutOfMemoryエラーが発生していることがわかります

1TISIGINFOダンプイベント"systhrow"（00040000）詳細
"java / lang / OutOfMemoryError" "スレッドの作成に失敗しました：retVal -1073741830、errno 12">受信1TIDATETIME日付：2012/07/17 at 20:03:17 1TIFILENAME> Javacore filename ：C：\ ServerApplication \ Tomcat5 \ bin \ javacore.34545719.4646464.4172.0003.txt

ヒープ情報は次のとおりです。 

Maximum Java heap size : 1500m    
Initial Java heap size : 256m

これは、初期および最大ヒープサイズ（32ビットJava）の構成です。

また、利用可能な空きヒープスペースがあることもわかります 

1STHEAPFREE    Bytes of Heap Space Free: 2D19F3C0   
1STHEAPALLOC   Bytes of Heap Space Allocated: 5DC00000

これは約750MBの空き容量ですよね？

そして、スレッドメソッドの分析から、スレッドの数が現在および中にあることが わかります。また695、これ49%が何を意味するのかわからないことがわかります。 また、0のトレッドがデッドロックされ、実行可能です。 java/lang/Object.wait(Native Method)39%sun/misc/Unsafe.park(Native Method)
NO JAVA STACK 1%
2%

この情報をどのように解釈するか、または根本的な原因を検出するためにここから先に進む方法がわかりません。
これについて何か助けはありますか？

4

5 に答える 5

9

この投稿によると：

java.lang.OutOfMemoryError: Failed to create a thread メッセージには 2 つの原因が考えられます。

  • 実行中のスレッドが多すぎて、システムが新しいスレッドを作成するための内部リソースを使い果たしました。
  • システムは、新しいスレッドに使用するネイティブ メモリを使い果たしました。スレッドには、内部 JVM 構造用のネイティブ メモリ、Java™ スタック、およびネイティブ スタックが必要です。

したがって、このエラーはメモリとはまったく関係がない可能性があります。作成されるスレッドが多すぎるというだけです...

編集：

695 個のスレッドがあるため、スタック サイズの 695 倍のメモリが必要になります。スレッド制限に関するこの投稿を考慮すると、利用可能な仮想メモリ空​​間に対してあまりにも多くのスレッドを作成しようとしていると思われます。

于 2012-07-27T08:21:18.103 に答える
7

-XX:+HeapDumpOnOutOfMemoryErrorフラグを指定して JVM を開始する必要があります。これにより、生成時にヒープ ダンプOutOfMemoryErrorが生成されます。

次に、@Steve が言ったように、MAT のようなツールを使用してダンプを分析し、どのオブジェクトが割り当てられているか、誰がそれらへの参照を保持しているかを確認できます。これにより、通常、JVM がメモリを使い果たしている理由についての洞察が得られます。

于 2012-07-27T07:03:42.570 に答える
5

言いたいことはわかりますが、どこから始めればよいかわかりにくい場合があります。

Eclipse Memory Analyzer (MAT)を見てください。JHat を使用して、プログラムのメモリ スナップショットをファイルにダンプします。このファイルは、再度開いて分析できます。

このファイルのブラウザは、プログラムによって作成されたすべてのオブジェクトの概要を非常にきれいに示しており、さまざまなレベルを調べて、何か疑わしいものがないかどうかを確認できます。

回答にコメントを追加しています...

実行可能な webapp がクラッシュしたら、MAT にダンプします。MAT は、何回も作成されているオブジェクトを教えてくれます。それがカスタム オブジェクトであり、多くの場合そうである場合は、簡単に見つけることができます。そうでない場合は、その親を見て、切断し、そこから滴り落ちることができます (グラフィックの例で申し訳ありませんが、現時点では SO に完全に焦点を当てているわけではありません :)。

ああ、言い忘れていましたが、プログラムをいくつかの条件下で数回実行し、そのたびにダンプを作成することができます。次に、傾向について各ダンプを分析できます。

しかし、私の場合は何を使用すればよいでしょうか?Tomcat で Web アプリを実行しています。

すみません、これも見逃しました。私が間違っていなければ、MAT は JVMプロセスをダンプするので、VM がボックスで実行されている限り、そのプロセスをダンプして何が起こっているかを確認できます。

別のコメントが部分的な解決策に変わりました...

これは実際よりも難しくなっています。真剣に、MAT を 1 回か 2 回実行してコツをつかめば、とても簡単です。クラッシュするまでアプリを実行します。それを捨てなさい。何かを変更。実行、クラッシュ、ダンプ。繰り返す。次に、MAT でダンプを開き、疑わしいと思われるものを比較します。

私がこれを学んでいたときに最も厄介だったのは、ダンプするプロセス IDを見つけることでした。

于 2012-07-27T06:50:37.967 に答える
2

IBM WebSphereの同様のメッセージには、次の行が表示されます

「スレッドの作成に失敗しました: retVal」

（プロセスの）一部のスレッドがヒープ上のメモリの大部分を要求しようとしていることを意味するネイティブOOMを示しています。

上記の IBM リンクには一連の手順が含まれており、その一部は IBM 固有のものです。見てください。

ネイティブのメモリ使用量の観点から:

  • 最大 Java ヒープ設定
  • JDBC ドライバー
  • JNI コードまたはネイティブ ライブラリ
  • 未使用クラスのガベージ コレクション。-Xnoclassgc が設定されていないことを確認してください。
  • スレッド プールの設定 (固定サイズのスレッド プール)
  • クラスローダーなどが多すぎますが、これらはあまり一般的ではありません。
  • javacore からのクラス/クラスローダーの数。

もう 1 つ確認できるのは、PermGenSpace です。サイズはどれくらいですか?

このリンクhttp://www.codingthearchitecture.com/2008/01/14/jvm_lies_the_outofmemory_myth.htmlは示唆しています

ヒープ割り当てを増やすと、実際にはこの問題が悪化します! これにより、コンパイラやその他のネイティブ コンポーネントが処理しなければならないヘッドルームが減少します。したがって、私の問題の解決策は次のとおりです。1.JVMに割り当てられたヒープを減らします。2. ネイティブ オブジェクトが適時に解放されないために発生するメモリ リークを取り除きます。

maxThreads の server.xml にも値を設定しましたか? デフォルトは 200 ですが、アプリには 695 があるようです。

于 2012-07-27T08:33:21.477 に答える
0

修理

新しいスレッドの作成中に IBM 技術情報java.lang.OutOfMemoryError に従いました。具体的には、「ulimit」コマンドを使用してデフォルトの 1024 から値を増やしました。

症状

[2/25/15 12:47:34:629 EST] 00000049 SystemErr     R java.lang.OutOfMemoryError: Failed to create a thread: retVal -1073741830, errno 11
[2/25/15 12:47:34:630 EST] 00000049 SystemErr     R     at java.lang.Thread.startImpl(Native Method)
[2/25/15 12:47:34:630 EST] 00000049 SystemErr     R     at java.lang.Thread.start(Thread.java:936)
[2/25/15 12:47:34:630 EST] 00000049 SystemErr     R     at org.eclipse.osgi.framework.internal.core.InternalSystemBundle.stop(InternalSystemBundle.java:251)
[2/25/15 12:47:34:630 EST] 00000049 SystemErr     R     at com.ibm.ws.runtime.component.RuntimeBundleActivator.shutdownEclipse(RuntimeBundleActivator.java:54)
[2/25/15 12:47:34:630 EST] 00000049 SystemErr     R     at com.ibm.ws.runtime.component.ServerCollaborator$ShutdownHook$1.run(ServerCollaborator.java:878)
[2/25/15 12:47:34:630 EST] 00000049 SystemErr     R     at com.ibm.ws.security.auth.ContextManagerImpl.runAs(ContextManagerImpl.java:5459)
[2/25/15 12:47:34:631 EST] 00000049 SystemErr     R     at com.ibm.ws.security.auth.ContextManagerImpl.runAsSystem(ContextManagerImpl.java:5585)
[2/25/15 12:47:34:631 EST] 00000049 SystemErr     R     at com.ibm.ws.runtime.component.ServerCollaborator$ShutdownHook.run(ServerCollaborator.java:850)
[2/25/15 12:47:34:631 EST] 00000049 SystemErr     R     at com.ibm.ws.runtime.component.ServerCollaborator$StopAction.alarm(ServerCollaborator.java:809)
[2/25/15 12:47:34:631 EST] 00000049 SystemErr     R     at com.ibm.ejs.util.am._Alarm.run(_Alarm.java:133)
[2/25/15 12:47:34:631 EST] 00000049 SystemErr     R     at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1815)

環境

CentOS 6.6 64 ビット IBM WAS 8.5.0.2 64 ビット

参考文献

于 2015-02-25T04:54:16.807 に答える