分析したいHotSpot JVMヒープダンプがあります。 VMは-Xmx31g
、およびヒープダンプファイルのサイズは48 GBです。
jhat
を試すことすらありません。これは、ヒープメモリの約5倍(私の場合は240 GB)を必要とし、非常に遅いためです。ArrayIndexOutOfBoundsException
でクラッシュします。そのタスクに使用できる他のツールは何ですか?ヒープダンプを分析用の効率的なデータ構造に変換する1つのプログラムと、事前に構造化されたデータで機能する他のツールを組み合わせたコマンドラインツールのスイートが最適です。
通常、私が使用するのは、 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つのメモを追加したいだけです。
この関連する質問に対する受け入れられた答えは、あなたにとって良い出発点を提供するはずです(ヒープダンプの代わりにライブjmapヒストグラムを使用します):
他のほとんどのヒープアナライザー(IBMを使用 http://www.alphaworks.ibm.com/tech/heapanalyzer )少なくともRAM Nice GUIツールを期待している場合はヒープ。
それ以外に、多くの開発者は、ライブスタック分析などの代替アプローチを使用して、何が起こっているのかを把握します。
なぜあなたのヒープがそんなに大きいのか疑問に思う必要がありますか?割り当てとガベージコレクションへの影響は大きくなければなりません。私はあなたのヒープにあるものの大部分が実際にデータベース/永続的なキャッシュなどに保存されるべきだと確信しています。
さらにいくつかのオプション:
この人 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 で、多くのお金を使わずに大きなヒープを移動できます。
YourKitを試すことをお勧めします。通常、必要なメモリはヒープダンプサイズより少し少なくなります(インデックスを作成し、その情報を使用して必要なものを取得します)
最初のステップ: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が利用可能になります。
あまり知られていないツール- http://dr-brenschede.de/bheapsampler/ は、大きなヒープに適しています。サンプリングによって機能するので、全体を読む必要はありませんが、少し複雑です。
Jprofilerを使用してみてください。大きな.hprofの分析に適しています。サイズが22 GB程度のファイルで試しました。
https://www.ej-technologies.com/products/jprofiler/overview.html
JXrayという興味深いツールに出会いました。制限付き評価トライアルライセンスを提供します。メモリリークを見つけることは非常に便利です。試してみてください。
これはコマンドラインソリューションではありませんが、私はツールが好きです:
ヒープダンプを、ホストするのに十分な大きさのサーバーにコピーします。元のサーバーを使用できる可能性は十分にあります。
ssh -X
経由でサーバーに入り、グラフィカルツールをリモートで実行し、Javaバイナリディレクトリのjvisualvm
を使用して、ヒープダンプの.hprof
ファイルをロードします。 。
このツールは、ヒープダンプ全体を一度にメモリにロードするのではなく、必要なときにパーツをロードします。もちろん、ファイルを十分に調べると、必要なメモリは最終的にヒープダンプのサイズに達します。