作業中のアプリケーションが突然クラッシュしました
java.io.IOException: ... Too many open files
問題を理解しているので、ファイルは開いているが閉じていないことを意味します。
もちろん、スタックトレースは事後に発生し、どのイベントエラーが発生する前に理解するのに役立ちます.
コードベースを検索して、アプリが高いストレス負荷にさらされているときにのみ発生するように見えるこの問題を見つけるためのインテリジェントな方法は何でしょうか.
作業中のアプリケーションが突然クラッシュしました
java.io.IOException: ... Too many open files
問題を理解しているので、ファイルは開いているが閉じていないことを意味します。
もちろん、スタックトレースは事後に発生し、どのイベントエラーが発生する前に理解するのに役立ちます.
コードベースを検索して、アプリが高いストレス負荷にさらされているときにのみ発生するように見えるこの問題を見つけるためのインテリジェントな方法は何でしょうか.
このような目的のために特別に設計されたツールを使用する最良の方法だと思います。
この小さな Java エージェントは、JVM でファイルをいつ、どこで、誰が開いたかを追跡するツールです。エージェントにこれらの操作をトレースさせて、アクセス パターンを調べたり、リークを処理したり、現在開いているファイルのリストと、それらをどこで、いつ、誰が開いたかをダンプできます。
さらに、「開いているファイルが多すぎます」という例外が発生すると、このエージェントはリストをダンプし、多数のファイル記述子が使用されている場所を見つけることができます。
YourKitにもこれに関するいくつかの機能があることを覚えているようですが、現時点では特定の情報を見つけることができません.
jvisualvm (JDK bin ディレクトリの Java 5.0 以降) を使用して、実行中のプロセスにアタッチしようとしましたか。実行中のプロセスを開いて、ヒープ ダンプを実行できます (古い JDK を使用している場合は、Eclipse または intellij または netbeans などを使用して分析する必要があります)。
JDK 7 では、ヒープ ダンプ ボタンは [監視] タブの下にあります。ヒープ ダンプ タブ、「クラス」サブタブが作成され、ファイルを開くクラスが大量に存在するかどうかを確認できます。もう 1 つの非常に便利な機能は、ヒープ ダンプの比較です。参照ヒープ ダンプを取得し、アプリを少し実行してから、別のヒープ ダンプを取得して 2 つを比較できます (比較するリンクは、取得した [heapdump] タブにあります)。 java には、クラッシュまたは OOM 例外でヒープダンプを取得するためのフラグもあります。ヒープ ダンプを比較しても、問題の原因となっている明らかなクラスが得られない場合は、そのルートをたどることができます。また、「インスタンス」ヒープ ダンプ diff のサブタブには、2 つのヒープ ダンプの間に割り当てられたものが表示されます。これも役立つ場合があります。
jvisualvm は、十分な言及を得られないすばらしいツールです。
何のOS?Linux/Mac の場合は、/proc の下に役立つ情報があります。Windows では、Process Explorerを使用します。
コードベースを検索する限り、おそらくキャッチまたは発生するコードを探しますIOException
-これを既にキャッチ/発生しているI / Oメソッドは、close()
呼び出しが必要になる可能性が高いと思います。