2010-12-07 24 views
5

私はJavaプロセスをXmx2000mで実行していますが、ホストOSはLinux CentOS、JDK 1.6 Update 22です。最近、私はプロセスで奇妙な動作を経験しています。私は、プロセッサ、ヒープ、およびPermメモリが完全ではない、スレッドとロードされたクラスがリークしていないことを監視するためにjconsoleを使用しています。 誰でも説明できますか?Javaプロセスが明らかな理由でぶら下がっています

+1

回答できません。あなたのコード内でどこでハングアップが発生しているのかを特定する必要があります(たくさんのログが役立ちます)。多分誰かが助けることができます。 –

+0

そう思った。誰かが同様の状況をデバッグすることに精通しているかどうかを尋ねるだけです。 –

答えて

6

考えられる理由がたくさんあり、十分な情報がないため、誰でもあなたに説明を与えることはできません。しかし、私はあなたがjstackプロセスがスレッドが何をしているのか把握してそこから取得するように掛かっていることをお勧めします。何かのdeadlockまたはthrashingのように聞こえます。

+0

+1私は古いチンパンジーですが、私は「ごみ箱」という言葉については知らなかったからです。古いチンパンジーなので、私はその行動を目撃しました(そして時々私は罪悪感を抱いていました)。しかし、それは名前が分かっていませんでした:) – SyntaxT3rr0r

+0

そして、その名前は口をこもっています。 –

+0

仮想メモリのスラッシングが発生した場合は、 'top'または(私のお気に入り)' vmstat 5'を使って表示されます。 –

2

aixと同意しますが、いくつかの推奨事項を追加したいと思います。 1.システムをチェックします。 topを実行して、システム自体が正常であり、CPUが100%でなく、メモリが使用可能であるかどうかを確認します。そうでない場合は、これを修正してください。 2.デッドロックの結果、アプリケーションがフリーズすることがあります。これをチェックして。

0

スレッドは、jvisualvmとjconsoleを使用してトレースすることができ、デッドロックも回避できます。個別のスレッドプールを持つ複数のネットワークサービスがあり、それらはすべて到達不能になります。

4

スレッドダンプを実行します。 Linux上でフォアグラウンドプロセスにアクセスできる場合は、ctrl-\を使用してください。または、jstackを使用してスタックをリモートでダンプします。あるいは、jconsole経由でJMXを介して実際にMBeans/java.lang/Threading/Operations/dumpAllThreadsに突き刺すことができます。

あなたのアプリについて詳しく知ることなく、原因を推測するのは難しいです。おそらくあなたのスレッドは、a)ブロックされているかb)終了しています。ブロックされていると、データベースやその他の操作でI/Oを待機しているか、ロックやモニタで待機している可能性があります(デッドロック)。デッドロックが存在する場合、スレッド・ダンプはどのスレッドがデッドロックされているか、どのロック、(Java 6では)ロックが取られたスタックに注釈を付けるかを示します。デッドロックはJMXメソッド(jconsoleからMBeans/java.lang/Threading/Operations/find[Monitor]DeadlockedThreads())で検索することもできます。

スレッドが未処理の例外を受け取って終了している可能性があります。スレッドのuncaughtExceptionHandlersをチェックするか、java.util.concurrent内のExecutorsを使用してください。

最後に、Javaでのポーズの他の古典的なソースはGCです。 -verbose:gcと他のGCフラグを付けて実行し、完全なGC収集を行っているかどうかを確認します。 MBeans/java.lang/Memory/Attributes/Verboseにフラグを反転することで、jconsoleでこれを動的にオンにすることもできます。

+0

知らなかった** jstack **:とても便利!おかげで – buzeeg

0

あなたは何をやっているのか詳しく説明できますか?メモリのための2000はかなりたくさんあります。

+0

これはメモリ集約型統計サービスです。データ構造を毎日スキャンする必要があります。 –

+0

RAMメモリを増やすことはできますか?たぶんそれは少し助けるかもしれません。ログを見て、円滑に実行されていないコードの部分や問題の原因を調べます。可能であれば、小さなモジュールに分解してテストしてください。 – thotheolh

+0

jvmが64ビットの場合、それを増やすことができます。私はそれが何かを持っていることを期待していません。これをチェックしてください。http://www.jadyounan.com/wp-content/uploads/2010/12/process.png –

0

クラッシュの直前のプロセスのjvisualvmを確認してください。ここ http://www.jadyounan.com/wp-content/uploads/2010/12/process.png

+0

答えとしてコメント/編集を追加することは、SOを使用する正しい方法ではありません。編集ボタンを使い、元の質問にこれを追加してください。 –

+0

その情報を追跡したい場合は、「プロセスがクラッシュしていないために*私のために働いていない」などとコメントしてください*など。 。 – SyntaxT3rr0r

1

[OK]を、私は共有したいと思ったいくつかの更新は、以下のとおりです。

NTPLする(Linuxの新しいスレッドライブラリ)とJava 1.6+ JVM間の非互換性があります。ランダムなバグにより、JVMがハングして100%CPUを消費します。

JVMを実行する前にLD_ASSUME_KERNEL = 2.4.1を設定すると、LD_ASSUME_KERMEL = 2.4.1がエクスポートされます。これはNTPLを無効にします:問題は解決しました!

互換性の理由から、私はまだNTPLを使用するソリューションを探しています。

関連する問題