問題タブ [heap-dump]

いくつかの大きな XML ファイルを読み取り、それらをデータベースに格納しています。800MB前後です。

多くのレコードを保存してから終了し、例外を発生させます。

Memory Analyzer を使用して、次のような .hprof ファイルを作成しました。

値を取得するためのセッターとゲッターがあります。この問題を解決するにはどうすればよいですか。どんな助けでも感謝されます。

JREを使用してメモリを増やしました。に。しかし、問題は解決しません

編集: XML ファイルを読み取るために scireumOpen を使用しています。

私が使用したコード例：

次のjvmパラメータに追加すると

-XX:+HeapDumpOnCtrlBreak

JVM を起動できなかったというエラーが表示されます。

Java 仮想マシンを作成できませんでした

私が使用しているJavaのバージョンは1.6.0_21.

私が間違っていることは何ですか？他のパラメータを設定する必要がありますか?

アプリケーションのメモリ リークを分析しています。Eclipse Memory Analyzerを使用して調査した結果、すべての参照を「保持」するルートは `

sun.awt.windows.WToolkit

そして今、この結果を解釈する方法がわかりません。私は、sun.awt.windows.WToolkit がリークを引き起こすべきではないと考えました。多分誰かがこの結果を解釈する方法を提案していますか?

私たちが確認しようとしている考えの 1 つは、 http: //www.jidesoft.com/ を使用している JIDE ライブラリが原因であるということですが、それと関係があるかどうかはわかりません。

DataNucleus を ORM マッピングとして、mysql をデータベースとして使用して、Spring コンテキストでアプリケーションを実行しています。

私たちのアプリケーションには、データベースへのデータ フィードの毎日のインポート ジョブがあります。データ フィードのサイズは、約 100 万行の挿入/更新に相当します。インポートのパフォーマンスは最初は非常に良好ですが、時間の経過とともに (実行されるクエリの数が増えるにつれて) 低下し、ある時点でアプリケーションがフリーズするか応答を停止します。アプリケーションが再び応答する前に、ジョブ全体が完了するまで待つ必要があります。

この動作はメモリ リークに非常によく似ており、潜在的な問題を検出するためにコードを注意深く調べましたが、問題は解消されませんでした。ヒープ ダンプから見つかった興味深い点の 1 つは、インポート中に org.datanucleus.ExecutionContextThreadedImpl (または HashSet/HashMap) がメモリの 90% (5GB) を保持していることです。（以下のダンプのスクリーンショットを添付しました）。私のインターネットでの調査によると、このリファレンスは Level1 Cache です (私が正しいかどうかはわかりません)。私の質問は、大規模なインポート中です。level1 キャッシュのサイズを制限/制御するにはどうすればよいですか。インポート中にキャッシュしないように DN に依頼することはできますか?

それが L1 キャッシュでない場合、メモリの問題の考えられる原因は何ですか?

このコードでは、挿入ごとにトランザクションを使用して、データベース内の大量のデータがロックされるのを防ぎます。2000挿入ごとにフラッシュメソッドを呼び出します

一時的な修正として、誰もアプリを使用していないときにインポート プロセスを夜間に実行するようにしました。もちろん、これが永遠に続くわけではありません。少なくとも誰かが私たちを正しい方向に向けて、より多くの調査を行い、修正を見つけることができるようにしてください.

誰かがヒープダンプをデコードする知識を持っているとよいでしょう

あなたの助けは、ここにいる私たち全員にとって非常に高く評価されます. どうもありがとう！

https://s3-ap-southeast-1.amazonaws.com/public-external/datanucleus_heap_dump.png

https://s3-ap-southeast-1.amazonaws.com/public-external/datanucleus_dump2.png

以下のコード - このメソッドの呼び出し元にはトランザクションがありません。このメソッドは呼び出しごとに 1 つのインポート オブジェクトを処理し、これらのオブジェクトを毎日約 100K 処理する必要があります。

}

私はダンプのデバッグに非常に慣れていないので、まだいくつか質問があります。

ダンプのデバッグに関するいくつかの質問を読み、コードをダンプに添付して、変数の値を確認できるようになりました。

私の質問は、生のヒープ データをプレビューする方法です。ダンプが非常に大きく、4 GB を超えるため、これが必要です。どこかで大きなメモリ リークが発生し、おそらくクラッシュが発生しました。それで、残ったいくつかの文字列を探します。

ところで。私は C++ でコーディングしており、デバッグには Visual Studio 2012 を使用していますが、他のプログラムをダウンロードすることもできます :)

VisualVM + VisualGC を使用して、このツールのメモリ使用量を分析しています。JVM とヒープ ダンプに関する私の誤解を明らかにしていると思われる、予期していなかったことに気付きました。

完全なコンテキストを提供するために、私がプロファイリングしているアプリケーションは、シリアライズされた巨大なブロブのルックアップを行い、その後、jammを使用してサイズを出力しています。その後、アプリはそのまま待機し、中止されるまで待機します。

VisualVM を使用すると、ヒープ使用量が予想どおりに増加していることがわかります。操作が完了し、アプリがスリープ状態になったら、VisualVM を使用して GC (または複数の GC、ボタンをクリックすることに夢中になります) をトリガーします。

• その時点での使用ヒープは1,849,825,472 bytesで、PermGem の使用スペースは25,864,448 bytesです。

• その時点で、明らかにしばらく時間がかかるヒープ ダンプを実行しますが、ヒープ ダンプが完了すると、使用されたヒープは1,944,542,296 bytesPermGen でほぼ同じになり25,892,800 bytesます。

• ここにパンチがあります: ヒープ ダンプは合計バイト数を示しています2,299,816,089。

そのような不一致を説明できるものは何ですか? 実験を数回繰り返しましたが、常に同じ結果が得られます。

例外はスローされませんが、まだデスクトップ フォルダに dump.bin ファイルが見つかりません。パスが間違っていますか?