ヒープ解析後のJavaヒープダンプとヒープサイズが異なる

Question

メモリリークが発生しました。

At the time of after-leak, 
    - top shows 50GB memory as residential 
    - heap dump file size is 25GB 
    - eclipse MAT analyzer tells me the heap size is 10GB 

At the time of before-leak, 
    - top shows 30GB memory as residential 
    - heap dump file size is 20GB 
    - eclipse MAT analyzer tells me the heap size is 10GB 

トップ、ヒープダンプサイズ、実際のヒープサイズの違いはかなり驚いています。 トップとヒープの違いは、ガベージコレクタヒープとネイティブヒープ領域の可能性があると推測しています。 しかし、どのようにヒープダンプのファイルサイズと実際のヒープサイズ（eclipse MATアナライザから）が異なるのでしょうか？

この問題に関する洞察はありますか？

UPDATE/ANSWER

の提案の中には、ウェブサイトは、 "ネイティブメモリトラッキング" を伝えるよう（https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr007.html）をjcmd使用するようにしています。しかし、あなたは慎重にページを読めば、あなたはそう

Since NMT doesn't track memory allocations by non-JVM code, 
you may have to use tools supported by the operating system 
to detect memory leaks in native code. 

が表示されます、ネイティブライブラリ内部リークの場合には、jcmdはオプションではありません。

インターネットを数日間クロールしてさまざまなプロファイラーを試した後、この問題の最も効果的なのはjemallocプロファイラーを使用することです。

このページは私を大いに助けました。 https://gdstechnology.blog.gov.uk/2015/12/11/using-jemalloc-to-get-to-the-bottom-of-a-memory-leak/

Answer 1

私は同様の状況を経験しました。違い（HPROFファイルサイズ - MATで示されるヒープのサイズ）は実質的にガベージ（到達不能オブジェクト）です。 MATの到達不能なオブジェクトヒストグラムはここで助けます。

jmap -F -dump:live,format=b,file=<file_name.hprof> <process_id>は、ガレージではなく生きているオブジェクトのみをダンプします。

Answer 2

topなどのOSレベルのツールは、JVMプロセスが消費するシステムメモリの量を示します。 -Xmxコマンドラインオプションで定義されたJavaヒープは、そのメモリの一部に過ぎません。ヒープとは別に、JVMはそれ自身のためにいくつかのメモリを必要とします。次に、それぞれが一定量のメモリを必要とするJavaスレッドがあります。そしてメタスペース/永続的な世代。その他いくつか。詳細については、this blog postおよびthis SO answerをお読みください。

ダンプファイルのサイズと実際のヒープサイズについては、@ arnab-biswasの回答は確かです。 MATは実際に使用されるヒープのサイズを、ライブオブジェクトによって消費されることを報告します。しかし、ヒープダンプにはゴミを含むヒープ全体が含まれています。

Answer 3

ネイティブメモリを監視するには、アプリケーションを-XX:NativeMemoryTracking=summaryまたは-XX:NativeMemoryTracking=detailで開始する必要があります。パフォーマンス上のペナルティがあることに注意してください。プロダクションで行う前に2度考えてください。

メモリトラッキングが有効な場合、jcmd <pid> VM.native_memory summaryを使用できます。他のコマンドも利用できます。https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr007.htmlをチェックするか、ネイティブメモリトラッキングを検索してください。

EDIT：回答する前にリンクをたどらなかったので、https://github.com/jeffgriffith/native-jvm-leaksのようなものを探している可能性があります。

Answer 4

ヒープダンプ： ヒープダンプは、特定の時点でのJavaプロセスのメモリのスナップショットです。このデータを永続化するためのさまざまな形式があり、フォーマットに応じてさまざまな情報が含まれますが、スナップショットには一般に、スナップショットがトリガーされた時点のヒープ内のJavaオブジェクトおよびクラスに関する情報が含まれます。通常、ヒープ・ダンプが書き込まれる前に完全なGCがトリガーされ、残りのオブジェクトに関する情報が含まれます。あなたが信頼できる/公式なソースから描画答えを求めているhttp://help.eclipse.org/neon/index.jsp?topic=/org.eclipse.mat.ui.help/welcome.html

Answer 5

MATに関連する情報については

はこちらをご覧ください。私はそれを試してみましょう。

1）私のJVMプロセス（Topで表示）で消費されるメモリが、ヒープのサイズよりも大きいのはなぜですか？ サイズ

JVMプロセスの合計メモリ消費量は、Javaヒープだけでなく、より多くのもので構成されているためです。いくつかの例：

- Generated (JIT:ed) code 
- Loaded libraries (including jar and class files) 
- Control structures for the java heap 
- Thread Stacks 
- User native memory (malloc:ed in JNI) 

信頼できる/公式ソース：Run-Time Data Areasとthis blog post

2）なぜ、ヒープ・ダンプのサイズはMATが報告したものよりはるかに大きいのですか？

MATは完全なヒープを表示しないため、索引作成中、Memory Analyzerは到達不能なオブジェクトを取り除きます。様々なガーベッジ・コレクター・アルゴリズムがいくつかのゴミを残す傾向があるからです。

信頼できる/公式ソース：MemoryAnalyzer/FAQ