Javaヒープダンプを確実に取得する方法

OutOfMemoryErrorsによってトリガーされた適切なヒープダンプを取得しようとすると、私のチームは困難に直面しています。特定の理由により、現在、HeapDumpOnOutOfMemoryErrorフラグを使用する代わりに、bashスクリプトから呼び出されたjmapでダンプを取得しています。ヒープサイズが約3 GBの64ビット1.6 JVMを使用しています。ヒープダンプは、90％の確率で失敗します（推定）。

メモリの問題のトラブルシューティングに使用できるクリーンなヒープダンプを取得する確率を向上させるためにできることはありますか？私は、jmapがJava 1.4で大きな問題を抱えていたことを読みましたが、それらの問題の大部分は今対処する必要があります。

あなたのオペレーティングシステムはどれですか？（コメントを追加できません）。

Solarisの場合、私たちはより良い結果が最初の（コアダンプを強制的に取得gcore <pid>）した後、コアダンプファイル（にjmapのを取り付けますjmap -heap:format=b <path to java bin> <path to core>）

gcore実行中のプログラムのイメージを生成する* nixユーティリティです。リンクを参照してください。

ManagementFactory.getThreadMXBean（）をクエリしてレポートを生成するJSPがあります。アプリがクラッシュした場合は役に立たない可能性がありますが、1分ごとにポーリングすると、何が起こっているかがわかります。

詳細はこちら。

外部からjmxを介してアプリケーションを監視できます。今後のOutOfMemoryを示すメトリックがわかっている場合は、例外がスローされる前にjmapの実行をトリガーできます。

ご提案いただきありがとうございます。

私たちがやったことは、ガベージコレクションログをアクティブに監視するスクリプトを書くことです。私たちの経験では、バックツーバックのフルGCはほとんど常にOOMの前にあるため、スクリプトがこのイベントを検出し、サーバーを負荷分散プールから適切に削除し、ヒープダンプを強制します。これにより、効果が大幅に向上しました。

これはかなり古い質問ですが、誰かがこれが役立つと思うことを期待して回答します。

jmapには-Fオプション（強制）があります。これは、過去にはうまく機能しないことが証明されています。-Fオプションを使用する場合は、jmapコマンドの一部としてjava.io.tmpディレクトリも指定することをお勧めします。JVMバージョン1.6.22で、一時ディレクトリの設定が原因でjmapユーティリティが正しく機能しないという問題がありました。

gdbを使用してコアダンプを取得することもできます。コアを取得すると、jmapはコアをヒープダンプに変換できます。