問題タブ [heap-dump]

過去数日間、サーバー上の JVM が OldGen の GC で 100% の CPU 時間を費やしている状態になっているのを確認しています。

A. ヒープに十分なスペースが残っているため、その必要はありません。

B. 彼らは何も回収していません。

スタック トレースを見て、ProcessExplorer の ThreadID をスタック ダンプの ThreadID と関連付けることで、それらが GC にあることがわかります。各 GC スレッドは約 4% の CPU を占有しています。

サーバーは 16 ギガ ヒープ (32 ギガの物理 RAM) を実行し、8 つのコアを備えています。稼働時間は通常約 30 日で、再起動は MS のパッチ適用要件のためだけに必要ですが、現在は 20 日でクラッシュしています。

これは、期間、時間スケール = 19 日のグラフです。 http://i45.tinypic.com/257qalu.png

これは、そのグラフのテールのズームです http://i48.tinypic.com/2duiccw.png

ご覧のとおり、持続時間は劇的に増加します。

これは、GC 後のヒープ使用量のグラフです。 http://i48.tinypic.com/znna4h.png

典型的なメモリ リークの場合、オレンジ色のピークがどんどん高くなり、ピークがなくなると予想されますが、このグラフが示すように、十分なヒープ スペースが残っています。

各サーバーのヒープ ダンプを取得しましたが、特に目立った問題はありません。いくつかの ehCache ストアがあり、アプリケーション コード、つまり「通常のもの」を見ることができます。

約 20 日前に行った最大の変更は、内部キャッシュを、ハード参照 (および明らかなメモリ リーク) を使用する無制限のハッシュマップからソフト参照で構成されるものに変更するベンダー パッチを実装することでした。原因、つまり、どういうわけか、ポイントの後にこれらのソフト参照を管理する際に大きなオーバーヘッドがあるのでしょうか?

次にどこを見るべきかについて誰かアイデアを持っていますか、または誰かが私のソフト参照理論を確認できますか?

これが私のjvm.argsです：

java.args=-server -Xms16000m -Xmx16000m -Dsun.io.useCanonCaches=false -XX:MaxPermSize=350m -Xloggc:e:/gcLogs/eRGCLogs.txt -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps - XX:+PrintGCDateStamps -XX:+UseParallelGC -XX:+UseParallelOldGC -Dnet.sf.ehcache.sizeof.filter=D:/jo3/java_ehCacheOpenSource/sizeOfExclusions.config -Xbatch -Dcoldfusion.rootDir={application.home}/.. / -Dcoldfusion.libPath={application.home}/../lib -Dcoldfusion.classPath={application.home}/../lib/updates,{application.home}/../lib,{application.home} /../gateway/lib/,{application.home}/../wwwroot/WEB-INF/flex/jars,{application.home}/../wwwroot/WEB-INF/cfform/jars,d:/ jo3/java,d:/JO3/java_ehCacheOpenSource/,D:/jo3/java_ehCacheMonitorProbe

私たちは Coldfusion を使用しています。これは、Java の上にある大規模なフレームワークのようなものです。

JVM バージョン: 1.6.0_29

要求どおり、「通常の」GC ログは次のようになります。

2013-03-19T22:11:36.670+1100: 1288665.702: [GC [PSYoungGen: 4695800K->471119K(4722112K)] 9301727K->5077046K(15644800K)、0.3584434 秒、ユーザー = 0.3584434 秒] sys0 = リアルタイム。 0.36秒] 2013-03-19T22：14：55.078+1100：1288864.099：[GC [PSyounggen：4783104K（4783104K）] 9327990K-> 5103936K（0.3789 SEC]、0.3789 SECS] 、実数 = 0.38 秒] 2013-03-19T22:17:46.749+1100: 1289035.760: [GC [PSYoungGen: 4654489K->517299K(4673792K)] 9260416K->5123227K(15596480K)、8 秒 80 ユーザー [Time] 0.41 秒 5 sys=0.00, real=0.41 秒] 2013-03-19T22:21:08.762+1100: 1289237.763: [GC [PSYoungGen: 4673779K->522660K(4738880K)] 9279707K->5143831K(15661568K) [Time 0.68K] user=5.97 sys=0.00, real=0.40 秒] 2013-03-19T22:23:42.683+1100: 1289391.675: [GC [PSYoungGen: 4582628K->530998K(4590976K)] 9203799K->5186242K(15513664K), 0.4317352 秒] [時間: user=6.24 sys=0.00, real=0.43 秒] 2013-03-19T22:26:11.096+1100: [0YoungGC0: 12805GC. 4590966K->518331K(4724096K)] 9246210K->5206959K(15646784K), 0.3914401 秒] [時間: user=5.99 sys=0.00, real=0.39 秒] 2013-03-19T22:27:44.076:3.095GC [PSYoungGen: 2602730K->447527K(4732864K)] 7291358K->5208743K(15655552K), 0.3725317 秒] [時間: user=5.80 sys=0.00, real=0.37 秒] 2013-03-19T22:27:82.414. ：[Full GC（System）[Psyounggen：447527K-> 0K（4732864K）] [PAROLDGEN：4761215K-> 4628296K（10922688K）] 5208743K-> 4628296K（15655552K）[PSPERMGEN：PSPERMGEN：PSPERMGEN：[PSPERMGEN] ] [時間: user=57.70 sys=0.06, real=4.30 秒] 2013-03-19T22:30:37.950+1100: 1289806.920: [GC [PSYoungGen: 4004416K->70948K(4690432K)] 8632712K->4699245K(15613120K), 0.1062227 秒] [時間: user=0.76 sys=0.00, real=0.11 秒] 2013-03-19T22:33:27.154+1100: [Gen 128PS19976] 4054116K->109175K(4092352K)] 8682413K->4737472K(15015040K), 0.1347919 秒] [時間: user=1.03 sys=0.00, real=0.13 秒] 2013-03-19T22:36:32.120:120GC [PSYoungGen: 4092343K->147318K(4712320K)] 8720640K->4775615K(15635008K), 0.1593523 秒] [時間: user=1.58 sys=0.00, real=0.16 秒] 24092343K->147318K(4712320K)] 8720640K->4775615K(15635008K), 0.1593523 秒] [時間: user=1.58 sys=0.00, real=0.16 秒] 24092343K->147318K(4712320K)] 8720640K->4775615K(15635008K), 0.1593523 秒] [時間: user=1.58 sys=0.00, real=0.16 秒] 2

障害モードの場合、GC ログは次のようになります。

2013-03-22T10:03:47.619+1100: 1504185.901: [GC [PSYoungGen: 0K->0K(5452736K)] 4413907K->4413907K(16375424K), 0.0114248 秒] [0.0114248 秒: user=0.160 = sys = real0. 0.01 秒] 2013-03-22T10:03:47.631+1100: 1504185.912: [フル GC [PSYoungGen: 0K->0K(5452736K)] [ParOldGen: 4413907K->4412613K(10922688K)] 4413907K4(1613907->4) PSPermGen: 358399K->358278K(358400K)]、5.4435442 秒] [時間: user=73.74 sys=0.14、real=5.44 秒] 2013-03-22T10:03:53.145+1100: 1504191.426: [GC [PSYoung219 K-6K-6K-6 >7734K(5449088K)] 4681833K->4422114K(16371776K)、0.0298728 秒] [時間: ユーザー=0.34 sys=0.00、実数=0.03 秒] 2013-03-22T10:03:53.175+1100: [フル GC4:6191. PSYoungGen: 7734K->0K(5449088K)] [ParOldGen: 4414379K->4415189K(10922688K)] 4422114K->4415189K(16371776K) [PSPermGen: 358399K->358371K(358400K)]、6033684 秒] [時間: user=36.33 sys=0.00, real=2.60 秒] 2013-03-22T10:03:55.788+1100: 1504194.069: [GC [PSYoungGen: 94969K->826K(5451328K)] 4510158K0->5K4(6 16374016K)、0.0133588 秒] [時間: user=0.16 sys=0.00、real=0.01 秒] 2013-03-22T10:03:55.802+1100: 1504194.082: [フル GC [PSYoungGen: 826K->0K(5451328K)] [ ParOldGen: 4415189K->4415348K(10922688K)] 4416015K->4415348K(16374016K) [PSPermGen: 358399K->358389K(358400K)]、2.7156884 秒] [Times: user=38.121, sys2.7 = real0]4415189K->4415348K(10922688K)] 4416015K->4415348K(16374016K) [PSPermGen: 358399K->358389K(358400K)], 2.7156884 秒] [時間: user=38.11 sys=0.201, real]4415189K->4415348K(10922688K)] 4416015K->4415348K(16374016K) [PSPermGen: 358399K->358389K(358400K)], 2.7156884 秒] [時間: user=38.11 sys=0.201, real]

3 GB近くのヒープメモリを使用するアプリケーションでヒープダンプを取得しようとすると、パフォーマンスへの影響を分析しようとしています。これは、メモリリークを監視する際に、最後の溝に対応する手段ではなく、予防的な手段としてヒープダ​​ンプを使用できるようにする必要があるかどうかを判断して理解するためです。誰かが以前にこのようなことを調べたことがありますか。そうです、助けていただけませんか。前もって感謝します。

を使用して、ヒープダンプがメモリ不足の例外で発生する場所を制御しようとしています。-XX:HeapDumpPath

私のJavaプロセスには現在の作業ディレクトリに書き込む権限がないため、user.homeディレクトリを指定しようとしています。絶対名がわからないので、次のような変数を使ってやってみますuser.home

試し-XX:HeapDumpPath=${user.home}/mydump.hprofましたが、うまくいきません

これを行うことは可能ですか？

outofmemoryerror で Java ヒープ ダンプを取得できない: これを試しました (one.exe は私の Java RCP アプリです):

しかし、助けにはなりませんでした。フォルダーパスにアクセスできます。heap.hprof のような名前を付けてみましたが、結果はありませんでした。誰かが私をここに導くことができますか?

open-jdk7 Java を使用して、glassfish 3.1.2 を実行しているマシンでヒープ ダンプを生成しようとしています。

次のコマンドを使用しています：

しかし、私はこのエラーを受け取り続けます:

ここに私の完全なJavaバージョンがあります:

正確な CentOS のバージョンは次のとおりです。

何か案は？

java.lang.OutOfMemoryError: GC limit exceededTomcatにデプロイされたWebアプリの高負荷時に何が発生するかを調査しようとしていました. ヒープ サイズは 8 GB に設定されました ( -Xms2048m -Xmx8192m)

ある時点で、GC アクティビティのオーバーヘッドが原因で、アプリケーションが応答しなくなります。フル GC が連続して複数回発生していることをログで確認できました。そこで、次のコマンドでヒープダンプを取得しました（jmap -F -dump:format=b,file=/root/dump2.hprof 4963）。ダンプを含むファイルのサイズは 9GB でした。ダンプが取得された後 (アプリは約 45 分間フリーズされました)、OutOfMemoryErrorスローされるまで複数のフル GC が発生しました。

GC アクティビティのログ サンプルを次に示します。

ヒープ ダンプを分析するために、Eclipse メモリ アナライザー (MAT) で開きました。残念ながら、MAT はヒープ サイズが 363.2MB (概要タブまたはヒープ ダンプの詳細タブ) であると表示しますが、GC ログによると、ヒープは 6467961K (6.4G) までいっぱいでした。Unreachable Objects Histogram は合計 75 511 736 (75 MB) を示します。ヒストグラム ビューでも、浅いヒープの合計が 380 837 136 であることが確認されました (363.2MB)

私の質問は、GC がメモリを再利用できない場合、MAT がヒープ ダンプからすべてのオブジェクトを表示しないのはなぜですか?

以下は、MAT にインポートされたヒープ ダンプのスクリーンショットです。

• 概要
• 到達不能

Java プログラムからヒープ ダンプを生成しようとしていますが、何を試しても、その方法がわかりません。

アクティブなjreプロセスからヒートダンプを取得できるはずのEclipseメモリアナライザー（プラグイン、次にスタンドアロン）をダウンロードしましたが、何もリストされていません。ドキュメントには、それらを生成する他の方法がいくつかリストされていますが、それらのいずれも機能しないようです。または、システムに存在しないように見えるものを参照しています。私がウェブ上で見つけることができたものから同じことが当てはまります...

プログラムがメモリ不足の例外を引き起こしているわけではなく、予想よりもはるかに多くのリソースを使用しているだけです。

私は、それがどのように正確に行われるべきかについて完全に途方に暮れています:/

どんな助けでも感謝します。

私は jvm プロセスを実行していましたが、ある日、メモリ不足の例外が発生しました。ログには、多くのメモリ不足エラーが見つかりました::

<1372410567863>

heapdump ファイルも生成されました。マットを使用して分析した後、スレッドからの大きなオブジェクトであることがわかりました。休止状態の共通オブジェクトorg.hibernate.engine.PersistenceContextであることはわかっていますが、どこから来たのかはわかりません。

小さなプログラムを書きたいのですが、メモリ不足エラーが発生したときにスレッドダンプ ファイルを自動的に生成します。

私の質問は、スレッド ダンプを正確に取得するのに最適な実行中のプログラムの時間はいつですか? ログ ファイルに最初にメモリ不足エラーが表示されますか?