問題タブ [heap-dump]

最近、jboss サーバーが xms 4096m、xmx 4096m、permsize 512m で実行されていたときに、hprof 形式でヒープダンプを作成しました。

生成された hprof ファイルは 5 GB を超えています。visualvm、mat アナライザー、または yourkit でヒープダンプをロードすると、合計バイト数が約 1 GB しか表示されません。キットの到達可能範囲を変更しようとしましたが、1 GB を超えて表示されません。

ファイルサイズと表示されたヒープダンプサイズのこの大きな違いが何を引き起こす可能性があるか考えていますか?

ps: jdk1.6.0_23 を使用しています

残念ながら、ここでスクリーンショットを送信することは許可されていません。

ファイルシステムでは、hprof のサイズは 5.227.659 kb であり、キットには次のように記載されています。

オブジェクト: 9.738.282 / 浅いサイズ 740 mb / 保持サイズ: 740 mb それらの間で到達可能な文字列: 6.652.515 (68%) / 浅いサイズ: 381 mb (51%) / 保持サイズ: 381 MB (51%)

保持される最大サイズは、206.810.176 の byte[] です。

kill -3 コマンドを使用して、30 秒ごとに Java ヒープ ダンプを取得するシェル スクリプトを実行したいと考えています。前もって感謝します。

Javaヒープダンプで、コードのどこ/どのスレッドがダンプを引き起こしたかを正確に知るにはどうすればよいですか？

呼び出し中にスレッドがロックされる

スレッド ダンプの一部は次のとおりです。

でロックされているように見えます

最後にヒープの詳細は、

例外をスローせずにスレッドは続行しません。

まず、変更を予定してい-XX:MaxPermSizeます。他にできることはありますか？

きっと、人々はこの例外に直面したに違いありません。

前もって感謝します。

HotSpotDiagnosticMXBeanクラスを使用せずに、アプリケーション内からヒープダンプを作成するにはどうすればよいですか。アクセス制限のためjava/rt.jar、に依存してコンパイルすることはできませんHotSpotDiagnosticMXBean。eclipse.compilerエラーを解決する方法は知っていますが、ビルド用に修正するにはどうすればよいですか？プログラムでヒープダンプを作成する方法に代わる方法はありますか？

• HotSpotDiagnosticMXBeanに依存しているため、このソリューションは機能しません。HotSpotに依存するヒープダンプ

発生時にアプリケーションによって作成された大きな（5GB）hprofダンプがありOutOfMemoryErrorます。（ XXの使用：HeapDumpOnOutOfMemoryError）。

残念ながら、このエラーが発生したときに収集されたログはありません。これを再作成するには数時間かかります。いくつかのツールがhprofからの例外スタックトレースまたはすべてのスレッドスタックなどを表示できるかどうかを期待していました。

現在MATを使用していますが、スレッド情報を取得する方法がわかりませんでした。どのツールを使用できますか？

（OOMが発生したときのhprofファイルにスレッド/呼び出しの場所に関する情報があるかどうかはわかりません）。

（通常の場合にスレッドダンプを取得する方法を知っています。ここでの問題は、すでに発生したイベントです。私が持っているのはhprofダンプだけです。）

Linuxマシン（およびおそらくUnixマシン）で生成されたJavaヒープダンプでは、アクセスが制限されています。ヒープは、プロセスの所有者のみが読み取ることができます（ACLマスクは600に設定されています）。これはセキュリティ上の理由によるものだと理解しています。ただし、動作を参照または説明しているドキュメントは見つかりませんでした。誰かが私にドキュメント（もしあれば）を教えてもらえますか？また、この動作をオーバーライドする方法はありますか？

メモリ使用量とCPU使用率を追跡するスレッドを作成したいと思います。

アプリケーションが高レベルに達した場合、ヒープダンプまたはスレッドダンプを生成したいと思います。

再起動せずにスレッドダンプランタイムを生成する方法はありますか？

皆さん、これは重複しているとは思いませんし、 OOMの質問を避ける方法の 1 つでもありません。これは真の知識の探求なので、反対票は控えてください...

ピクセルがあるJPEGと想像してください。「 」500x500のとおりにロードします。ARGB_8888bad as it gets

私は Android が割り当てることを期待しています500x500x4 bytes = a little under 1MBが、ヒープ ダンプを見ると、Android がかなり多く、多くの場合5-10何倍も多く割り当てていることがわかります。

ここでは、スタック トレースが示すOOMSに関する質問をよく見かけますが、単にイメージのバイトを保持するために必要なサイズよりも常にはるかに大きくなっています。OPは通常、いくつかの反対票をキャッチし、在庫の回答と、メモリの使用量が少ないこと（Romainに感謝します！）とスケーリングに関するコメントで攻撃されます。ここには目に見える以上のものがあると思います。heap request of say 15MB

これがなぜなのか知っている人はいますか？

明らかな答えがない場合は、役立つ場合はSSCCEをまとめます。

PS。バッキングビットマップのメモリ使用量について話しているので、JPEG と PNG などは無関係であると思います。これは単に x 倍 y 倍の BPP です - それとも遅いのでしょうか?