問題タブ [concurrent-mark-sweep]

完全な GC が発生したときに古い世代で圧縮を行うように CMS コレクターに指示することを理解しています。

しかし、それを正しく理解しているかどうかを確認したい (さまざまな情報源からつなぎ合わせた):

完全な GC は、ワールドを一時停止し、(CMS のリマーク フェーズの結果を使用して) 古い世代を収集して圧縮し、次に若い世代を収集し、オブジェクト (存在する場合) を昇格させ、世界を再開します。

この時点で、古い gen にゴミが浮遊している可能性があり、UseCMSCompactAtFullCollectionそれらをクリーンアップして古い gen を再度圧縮します (基本的に古い gen の別の GC)。とにかく世界が止まっているので、もう少し圧縮する価値があるかもしれません。

この説明は正しいですか？重要な詳細を見逃していませんか? ありがとう

Java -バージョン

Java バージョン "1.6.0_21" Java(TM) SE ランタイム環境 (ビルド 1.6.0_21-b07) Java HotSpot(TM) 64 ビット サーバー VM (ビルド 17.0-b17、混合モード)

jvm 構成:

-server -XX:+DoEscapeAnalysis -XX:+CMSParallelRemarkEnabled -XX:+UseBiasedLocking -XX:ParallelGCThreads=20 -XX:+UseLargePages -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSConcurrentMTEnabled -XX:SurvivorRatio=8 - XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=15 -XX:ReservedCodeCacheSize=128m -XX:+UseCodeCacheFlushing -XX:NewRatio=3 -XX:+DisableExplicitGC -Dsun.rmi.dgc.client.gcInterval=1800000 -Dsun.rmi. dgc.server.gcInterval=1800000 -Djava.net.preferIPv4Stack=true -Xss1024k -Xms8192m -Xmx8192m -XX:MaxPermSize=1024m -XX:PermSize=1024m -Dremoting.bind_by_host=false -Dorg.jboss.resolver.warning=true - Dclient.encoding.override=UTF-8 -Dfile.encoding=UTF-8 -Dnet.sf.ehcache.skipUpdateCheck=true -Dorg.apache.xerces.xni.parser.XMLParserConfiguration=org.apache.xerces.parsers.XIncludeAwareParserConfiguration

-Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+HeapDumpOnOutOfMemoryError -Djava.net.preferIPv4Stack=true -Dorg.apache. el.parser.COERCE_TO_ZERO=false -Dorg.apache.catalina.connector.Request.SESSION_ID_CHECK=false

CMS-concurrent-preclean abort が原因で CMS-concurrent-sweep の実行に時間がかかるのでしょうか? ユーザーに 48 秒間のワールド ストップを体験させますか? 上記の gc ログからの推論は何ですか。

8GB のメモリと 4 つの CPU を搭載したマシンで Java アプリケーションを実行しています。しかし、ストレステストでアプリケーションを長時間実行した後、メモリが完全にいっぱいになり、gc サイクルが完了するまでに時間がかかるように見えるため、ガベージコレクターの問題が観察されますが、考えられる原因とその解決策を理解できません。リクエストが完了するまでの平均レイテンシーに大きな違いはありません。しかし、多くのスレッドを同時に処理することはできません。

次のパラメータでアプリケーションを開始しました

top コマンドの出力

メモリがいっぱいになった後のサンプル GC ログ

なぜメモリがいっぱいになるのか、それを克服してより高い負荷でアプリを長期間実行できるようにするために何ができるのかという結論に達したかったのです。そうするのを手伝ってください。

私たちの顧客の 1 人が、長いガベージ コレクションの実行が原因であると思われる重大なパフォーマンスの問題に遭遇しました。

Java バージョン: 1.7.0_67 JVM 引数: -Xms10240m -Xmx16386m -XX:NewSize=2048m -XX:MaxPermSize=150m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails ...

追加情報

アプリケーションは、Web アプリケーションのサーバー バックエンドです。サーバーは、SQL データベースと複数の ERP システムに接続します。このデータは処理され、Web クライアントに送信されます。この顧客は特に、この単一サーバーを介してデータにアクセスする世界中の約 50 人のユーザーを抱えています。

• OS: Windows Server 2008 R2 データセンター + SP1
• CPU: Xeon E5-2660 (4 コア + HT)
• RAM: 32GB

これまでに試したこと

• Xmx と Xms の増加 (最高のパフォーマンスを得るには、Xms が同一であるか、少なくとも Xmx に近い必要があることをお読みください)
• 若い世代のサイズをいじる（比率1、2、3）
• PermGeneration の増加
• さまざまなGCバリアントを試しました

gc ログの一部を次に示します。gc の持続時間が時間の経過とともに増加し、約 !!!17 秒でピークに達することがはっきりとわかります!!!.

これらの問題の原因は何ですか? いじくり回す必要のある JVM 引数はありますか?

更新 / 2016.03.25

VisualVM を実行した後、/ 問題の 1 つを見つけたようです: Young Generation は現在 4GB に設定されています - Eden と Survivor の比率がかなりずれているようです... Eden = 3.5 GB で、Survivor = 0.5 GB As常に多くの新しいオブジェクトが生成されます (これについてはさらに調査する必要があります)。Eden には 0.5 GB 以上 (1 ～ 2 GB 程度) が格納されます。サバイバーはそれを保持できないため、メジャー GC がトリガーされます。

発生する新しい質問:

1. 私の仮定は間違っていますか？
2. 次のステップは、生存率を手動で設定することだと思います。私のケースに基づいた提案はありますか？
3. AdaptiveSizePolicy を無効にする必要がありますか? (-XX:-UseAdaptiveSizePolicy)
4. コードでトリガーされた手動 GC がまったくないのに、GC ログに原因が「System.gc()」として表示されるのはなぜですか (すべてのクラスを逆コンパイルしてチェックします)。

2016-03-25T04:59:55.726+0100: 14992.418: [Full GC (System.gc())2016-03-25T04:59:55.726+0100: 14992.418: [CMS: 265708K->265749K(6291456K), 1.1520720 secs] 507160K->265749K(10066368K), [CMS Perm : 54875K->54875K(91504K)], 1.1523255 secs] [Times: user=1.14 sys=0.00, real=1.14 secs]

古いログ / 24.03.2016

開始後の最初のいくつかのログ:

今度いつか：

GC 期間のピーク時:

完全なログ: http://pastebin.ca/3409912

Oracle の 64 ビット Java 1.8 Hotspot JVM を実行しています。私は、異なる GC メカニズムが使用されている場合に、JVM の動作の違いに頭を悩ませて、圧縮されたオブジェクト ポインターを起動しようとしています。例えば：

他のいくつかの G1GC ノブを変更しようとしましたが、G1 の 32736 MB を超えるヒープ サイズで圧縮ポインターの最適化を開始できません。しかし、明らかにわかるように、CMS は最大 32766 MB のヒープ サイズに圧縮ポインタを使用できます。さまざまな GC アルゴリズムのこのしきい値を制御するものを理解しようとしています。

CMS を使用して同時モードの障害または昇格の障害が発生した場合は常に、シングル スレッドを使用してフル GC を実行します。フル GC ペナルティを減らすために並列コレクターを使用してフル GC を実行できなかったのはなぜですか?

CMS がフル GC で機能する 4 つの高レベル フェーズがあります。

1. イニシャルマーク :- ストップ・ザ・ワールド(STW)
2. 同時マーキング :- 同時に実行
3. 備考:- STW
4. 同時スイープ:- 同時に実行

読んだ後、CMS の高度な理解を得ました

http://www.tikalk.com/java/garbage-collection-serial-vs-parallel-vs-concurrent-mark-sweep/およびhttps://plumbr.eu/handbook/garbage-collection-algorithms-implementations/concurrent -マークアンドスイープ

私の質問はInitial Mark、なぜ最初のマークステージがフェーズの STW なのですか? これは和解の最終段階なので、STW として発言フェーズだけを使用することはできませんか。

同様にSweeping phase、オブジェクトの物理的な場所の変更を意味する圧縮が必要になるため、STW ではないのはなぜですか。オブジェクトがアプリによって参照され、並行スレッドが物理的な場所を変更した場合、それは問題になりませんか?

ここに何かが欠けていることは知っていますが、それは何ですか?

この問題が非常に似ていることを前もって 認めます。明らかな理由がない。私が投稿しているのは、1. これらのスレッドが 1 年以上前のものであり、2. この動作の開始の根本的な原因を見つける方法を学びたいからです。

RHEL5/Redhat 5.11、Java 6 で実行されている OAS/OC4J (これは私たちのせいではありません!) 24 時間年中無休の Java アプリケーション サーバーです。頻繁な CMS 保有スペース サイクル。これは、若いスペースと在職期間のスペースの両方に十分なスペースがある場合でも発生します。このトピックに関する私の読みでは、CMS の Tenured サイクルは通常、Tenured (Old gen) スペースが容量の約 92% になったときに開始されることを示唆しています。しかし、これは 30% の容量がさらに少ない場合でも繰り返し発生しています。また、総ヒープが全体的なヒープ使用量のデフォルトの 45% 値 (別名InitiatingHeapOccupancyPercent.

最近のコードの変更をまだ確認しており、いくつかのことを試しましたが、これらの問題は解決しません。そのため、dev/qa 環境での取り組みは進行中ですが、本番サーバー以外で再現することはできません。

ここには主に 3 つの質問があると思います。

1. CMS サイクルの初期マーク フェーズを頻繁に (時期尚早に) 引き起こしている可能性があるのは何ですか。そして、これをどのように確認または調査できますか? たとえば、巨大なオブジェクトなどの現在のメモリ割り当て (eden、survivor、old-gen) のさまざまなセグメントを調べますか?
2. -XX:+UseCMSInitiatingOccupancyOnlyandの使用について読んだことがあります-XX:CMSInitiatingOccupancyFraction=NN（たとえば、上記の記事で）。NN の妥当な (== 安全な) 値は何でしょうか? また、このようにデフォルトの CMS エルゴノミクスをオーバーライドするリスクは何ですか?
3. 他に検討または調査すべきことはありますか?

問題の詳細は次のとおりです。

• したがって、これまでのところ、これを本番環境以外で再現することはできません. したがって、デバッグやチューニングはオプションではありません
• 夜間の cron ジョブを使用して、完全な GC を強制し、jmap -histo:live pidを介して断片化を軽減します。
• 私たちのJVMコマンドライン引数wrtメモリは以下の通りです:

-XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintTenuringDistribution -XX:-TraceClassUnloading -XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:+HeapDumpOnOutOfMemoryError -XX:+ExplicitGCInvokesConcurrent -XX:+UseCMSCompactAtFullCollection -Xms10g -Xmx10g -Xmn3g -XX:SurvivorRatio=6 -XX:PermSize=256m -XX:MaxPermSize=256m -XX:TargetSurvivorRatio=80 -XX:ParallelGCThreads=8

注: 最近、やや絶望的な実験として、若い世代を 3.5g に上げようとしました。（生産中！）実際に識別可能な違いは観察されませんでした

• の出力jmap -heap。注: From Space常に 100% 占有されているようです。これは正常ですか、それとも何かを示していますか?:

• 社内の GC ログ パーサーからの出力。頻繁なイニシャル マーク (IM)/リマーク (RM) サイクルと、若年/在職期間の低い占有率を示しています。Young 世代の占有率が 98.30% までゆっくりと成長し、その後すぐに期待されるParNew(PN) Young GCを実行することがわかります。

• 上記の出力の最初のイニシャル マーク (IM) から始まる実際の G​​C ログ14:17:03.057出力。上記と同様に切り詰められていますが、完全を期すために ParNew Young GC を示しています。

Alexey の優れた観察と提案に基づいて、本番環境で Perm Generation を強化してみます (また報告します)。しかし、彼の推測の予備検証として、ホストの 1 つですべてのコンテナ JVM の perm gen の使用状況を調査したところ、非常に妥当と思われます。以下のスニペットでは、PID=2979 (perm gen 容量 92%) が、一定の CMS 収集動作を示すものです。

これは GC アクティビティのキャプチャです。

これは、フル GC がある場合です。

それは一時停止ですか？

私はこれを見ることを期待していました：

しかし、これは JVM の開始直後に一度だけ発生し、二度と発生しませんでした。

JVM が CMS GC の使用を停止したと考えていたので、以下を確認しました。

コンカレント マーク スイープ GC は適切に実行されているようです。

ログに CMS GC イベントが記録されずにフル GC が発生するのは正常ですか?

最初のマークとリマークのフェーズが発生しない場合、ストップオブザワールドの一時停止がないということですか?

マシンは Windows、24 コア、JDK 8u101 です。

使用されるフラグは次のとおりです。