web-dev-qa-db-ja.com

大規模なJavaヒープダンプを分析するためのツール

分析したいHotSpot JVMヒープダンプがあります。 VMは-Xmx31g、およびヒープダンプファイルのサイズは48 GBです。

  • jhatを試すことすらありません。これは、ヒープメモリの約5倍(私の場合は240 GB)を必要とし、非常に遅いためです。
  • ヒープダンプを数時間分析した後、Eclipse MATはArrayIndexOutOfBoundsExceptionでクラッシュします。

そのタスクに使用できる他のツールは何ですか?ヒープダンプを分析用の効率的なデータ構造に変換する1つのプログラムと、事前に構造化されたデータで機能する他のツールを組み合わせたコマンドラインツールのスイートが最適です。

72
Roland Illig

通常、私が使用するのは、 Eclipse Memory Analyzer に含まれるParseHeapDump.shであり、 ここ に記述されています。 Linux .Zipディストリビューション、解凍します)。シェルスクリプトは、GUIからヒープを解析するよりも少ないリソースで済みます。さらに、より多くのリソースを備えた強力なサーバーで実行できます(-vmargs -Xmx40g -XX:-UseGCOverheadLimitのようなものを最後の行の最後に追加して、スクリプト。たとえば、変更後、そのファイルの最後の行は次のようになります

./MemoryAnalyzer -consolelog -application org.Eclipse.mat.api.parse "$@" -vmargs -Xmx40g -XX:-UseGCOverheadLimit

./path/to/ParseHeapDump.sh ../today_heap_dump/jvm.hprofのように実行します

それが成功すると、.hprofファイルの横にいくつかの「インデックス」ファイルが作成されます。

インデックスを作成した後、そこからレポートを生成し、それらのレポートをローカルマシンにコピーして、それだけで犯人を見つけることができるかどうかを確認します(インデックスではなく、レポートだけでなく)。 レポートの作成 のチュートリアルです。

レポート例:

./ParseHeapDump.sh ../today_heap_dump/jvm.hprof org.Eclipse.mat.api:suspects

その他のレポートオプション:

org.Eclipse.mat.api:overviewおよびorg.Eclipse.mat.api:top_components

それらのレポートが十分ではなく、さらに掘り下げる必要がある場合(つまりoqlを使用して)、ローカルマシンのインデックスとhprofファイルをscpし、ヒープダンプを開きます(インデックスは同じディレクトリにあります) Eclipse MAT GUIを使用したヒープダンプ)。そこから、実行するのにあまり多くのメモリは必要ありません。

EDIT:2つのメモを追加したいだけです。

  • 私の知る限り、インデックスの生成のみがEclipse MATのメモリ集約型の部分です。インデックスを取得したら、Eclipse MATからの処理のほとんどはそれほど多くのメモリを必要としません。
  • シェルスクリプトでこれを行うことは、ヘッドレスサーバーで実行できることを意味します(通常、ヘッドレスサーバーでも実行できます。通常、それらは最も強力なサーバーであるためです)。そして、そのサイズのヒープダンプを生成できるサーバーがある場合は、ヒープダンプの多くを同様に処理できる別のサーバーがある可能性があります。
64
Franz See

この関連する質問に対する受け入れられた答えは、あなたにとって良い出発点を提供するはずです(ヒープダンプの代わりにライブjmapヒストグラムを使用します):

大規模メモリリークを見つける方法Javaヒープダンプ

他のほとんどのヒープアナライザー(IBMを使用 http://www.alphaworks.ibm.com/tech/heapanalyzer )少なくともRAM Nice GUIツールを期待している場合はヒープ。

それ以外に、多くの開発者は、ライブスタック分析などの代替アプローチを使用して、何が起こっているのかを把握します。

なぜあなたのヒープがそんなに大きいのか疑問に思う必要がありますか?割り当てとガベージコレクションへの影響は大きくなければなりません。私はあなたのヒープにあるものの大部分が実際にデータベース/永続的なキャッシュなどに保存されるべきだと確信しています。

6
Michael

さらにいくつかのオプション:

この人 http://blog.ragozin.info/2015/02/programatic-heapdump-analysis.html

実際にファイルをメモリにロードする代わりに、ヒープダンプファイルを介して「クエリスタイル」インターフェースを公開するだけのカスタムNetbeansヒープアナライザーを作成しました。

https://github.com/aragozin/jvm-tools/tree/master/hprof-heap

「彼のクエリ言語」が、ここで受け入れられた回答で言及されたEclipse OQLよりも優れているかどうかはわかりませんが。

JProfiler 8.1(ユーザーライセンスで499ドル)も said で、多くのお金を使わずに大きなヒープを移動できます。

4
rogerdpack

YourKitを試すことをお勧めします。通常、必要なメモリはヒープダンプサイズより少し少なくなります(インデックスを作成し、その情報を使用して必要なものを取得します)

3
Peter Lawrey

最初のステップ:RAMの量を増やします。MATに割り当てます。デフォルトではそれほど大きくなく、大きなファイルを開くことができません。

MAC(OSX)でMATを使用する場合、MemoryAnalyzer.app/Contents/MacOSにMemoryAnalyzer.iniファイルがあります。そのファイルを調整して、それらを「取得」させるのは、私にとってはうまくいきませんでした。代わりに、このファイルの内容に基づいて変更された起動コマンド/シェルスクリプトを作成し、そのディレクトリから実行できます。私の場合、20 GBのヒープが必要でした。

./MemoryAnalyzer -vmargs -Xmx20g --XX:-UseGCOverheadLimit ... other params desired

ターミナルを介してContents/MacOSディレクトリからこのコマンド/スクリプトを実行するだけで、GUIをさらにRAMが利用可能になります。

3
Michael Shvets

あまり知られていないツール- http://dr-brenschede.de/bheapsampler/ は、大きなヒープに適しています。サンプリングによって機能するので、全体を読む必要はありませんが、少し複雑です。

2

Jprofilerを使用してみてください。大きな.hprofの分析に適しています。サイズが22 GB程度のファイルで試しました。

https://www.ej-technologies.com/products/jprofiler/overview.html
0
Selvam M

JXrayという興味深いツールに出会いました。制限付き評価トライアルライセンスを提供します。メモリリークを見つけることは非常に便利です。試してみてください。

0

これはコマンドラインソリューションではありませんが、私はツールが好きです:

ヒープダンプを、ホストするのに十分な大きさのサーバーにコピーします。元のサーバーを使用できる可能性は十分にあります。

ssh -X経由でサーバーに入り、グラフィカルツールをリモートで実行し、Javaバイナリディレクトリのjvisualvmを使用して、ヒープダンプの.hprofファイルをロードします。 。

このツールは、ヒープダンプ全体を一度にメモリにロードするのではなく、必要なときにパーツをロードします。もちろん、ファイルを十分に調べると、必要なメモリは最終的にヒープダンプのサイズに達します。

0
kap