1

製品版のアプリの 1 つで問題が発生しています。

VMは次のように構成されています

-XX:MaxPermSize=300M -Xms2560M -Xmx2560M -Xloggc:/app/log/gc-admin-20120619-123754.log -verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction =80 -XX:+DisableExplicitGC -XX:CMSMaxAbortablePrecleanTime=8000

私が見逃して適用される 2 つのオプションは XX:PermSize - MaxPermSize と同じにする必要があります (推奨) CMSInitiatingOccupancyFraction が使用されている場合は UseCMSInitiatingOccupancyOnly です。

ただし、パイプラインのこれらの変更により、問題が解決されるとは確信していません。

コンカレント モードの障害が発生していますが、障害が発生すると、ワールド コレクションの停止に永遠の時間がかかります。現時点では、その理由について少し戸惑っています!!

ここにいくつかのサンプルがあります

168427.476: [GC [1 CMS-initial-mark: 2135988K(2578880K)] 2141041K(2617216K), 3.1029210 秒] [時間: user=0.02 sys=0.01, real=3.10 秒] 168430.596: [CMS-concurrent-mark-start ] 168441.309: [GC 168441.309: [ParNew: 36520K->36520K(38336K), 0.0000210 秒]168441.309: [CMS168747.453: [CMS-concurrent-mark: 309.313/316.857 秒] [Times: = user5, = sys5.8 real=316.81 秒] (同時モード障害): 2561882K->1310927K(2578880K)、767.0309740 秒] 2598402K->1310927K(2617216K)、[CMS パーマ: 96774K->96171K(158792K)]、[ユーザー] 3 秒 6.0 秒 7.0 =3.87 sys=5.06, real=766.92 秒]

STWコレクション全体について私が心配しているのは、766.92秒のタイミングですが、CPU時間は「user = 3.87 sys = 5.06」だけなので、残りの時間はここで何が起こっているのでしょうか?? これは私が困惑しているところです。アプリ内のすべてのスレッドを停止するのにそれほど時間がかかるとは想像できません!! もしかしてスラッシング??

169545.325: [GC [1 CMS-initial-mark: 2141069K(2578880K)] 2166025K(2617216K), 0.0530140 秒] [Times: user=0.05 sys=0.00, real=0.06 secs] 169545.379: [CMS-concurrent-mark-start ] 169558.635: [CMS-concurrent-mark: 10.407/13.256 秒] [Times: user=7.58 sys=0.53, real=13.25 secs] 169558.635: [CMS-concurrent-preclean-start] 169558.684: [CMS-concurrent-preclean: 0.048/0.048 秒] [Times: user=0.01 sys=0.00, real=0.05 secs] 169558.684: [CMS-concurrent-abortable-preclean-start] 169560.544: [GC 169560.544: [ParNew169560.605: [CMS-concurrent-abortable] -preclean: 0.210/1.921 秒] [時間: user=0.93 sys=0.05, real=1.92 秒] 169560.846: [GC[YG 占有: 1906 K (38336 K)]169560.846: [再スキャン (並列) , 0.0046910 秒]169560.851 : [weak refs 処理、0.0000990 秒] [1 CMS-remark: 2350428K(2578880K)] 2352335K(2617216K)、0.0048570 秒] [時間:user=0.01 sys=0.00, real=0.01 secs] 169560.853: [CMS-concurrent-sweep-start] 169568.204: [CMS-concurrent-sweep: 7.351/7.351 secs] [Times: user=0.91 sys=0.09, real=7.34秒] 169568.204: [CMS-concurrent-reset-start] 169568.211: [CMS-concurrent-reset: 0.007/0.007 秒] [Times: user=0.01 sys=0.00, real=0.01 secs]

これは問題を示していません

252247.318: [GC [1 CMS-initial-mark: 2069401K(2578880K)] 2075094K(2617216K), 1.5311840 秒] [時間: user=0.01 sys=0.00, real=1.53 秒] 252248.849: [CMS-concurrent-mark-start ] 252350.336: [GC 252350.336: [ParNew: 20984K->4222K(38336K), 12.2251190 秒]252362.561: [CMS252520.780: [CMS-concurrent-mark: 161.376/271.922 秒] [Times: = 2.6 user, sys1.5 real=271.89 秒] (同時モードの失敗): 2232372K->1061586K(2578880K)、407.2310250 秒] 2240205K->1061586K(2617216K)、[CMS Perm: 97525K->97381K(160480K)]、8 秒 5 ユーザー:4 秒 4 =4.23 sys=2.99, real=419.39 秒]

そして、別のすごい「Times: user=4.23 sys=2.99, real=419.39 secs」。CPU 時間はマイナーな「user=4.23 sys=2.99」ですが、全体の時間は「419.39」です。VM が長時間ハングする原因は何ですか?? 10秒以内のSTW回収で2.5gを回収するのが理想!!

しきい値 CMSInitiatingOccupancyFraction を下げるつもりですが、そのようなコレクション時間では役に立たないと思います!! スムーズに実行されるコレクションもあれば、そうでないコレクションもありますが、私が言ったように、世界が完全に停止するタイミングが心配です。

https://blogs.oracle.com/jonthecollector/entry/what_the_heck_s_aを読み ました

そしてjdk6を使用しています。

誰かが以前に似たようなことを経験したことがありますか?

4

3 に答える 3

2

ご覧のとおり、並行モードが失敗すると、stop-the-worldコレクションにフォールバックします。私の理解では、これは、より効率的なコピーコレクターではなく、マークスイープコンパクトコレクターを使用して実行される 可能性があります。

これは、コレクションに時間がかかる理由を完全に説明しているわけではありません。ただし、VMスラッシングはもっともらしい理論であり、あなたの証拠はこれを裏付けています...しかし、確実にするために、VMスワップ/ページングレートのOSレベルの測定値を取得する必要があります。（JVMがスラッシングを引き起こす場合、ヒープがいっぱいになると、完全なガベージコレクション中に最悪になる可能性が高くなります。）

並行モードの失敗の原因に戻ると、リンク先のブログには、最も可能性の高いことが何が起こっているかが記載されています。

  • ヒープがいっぱいになる、または
  • オブジェクトの割り当て率が高すぎる、または
  • オブジェクトの割り当て率が変動しすぎる、または
  • 上記のいくつかの組み合わせ。

提案された解決策は次のとおりです。

  • ヒープサイズを増やします。
  • CMSInitiatingOccupancyFractionの値を減らします
  • CMSIncrementalSafetyFactorの値を増やします

もう1つは、スループットコレクターに切り替えて、完全なコレクションを実行するときに時折「長い」一時停止が発生することです。

問題がVMのスラッシングである場合、あなたは岩と困難な場所の間にいます。マシンまたは仮想で使用可能な物理RAMの量に対して、仮想メモリを過剰に割り当てました。オプションは、マシン/仮想にRAMを増やすか、ヒープサイズを減らしたり、サービスやアプリケーションを停止したりすることで、システムの仮想メモリ使用量を減らすことです。

（仮想化を使用しているかどうかに関係なく、仮想メモリのスラッシングが発生する可能性があることに注意してください。仮想化を使用すると、メモリを過剰に割り当てたいという誘惑が強くなります...）

于 2012-06-22T12:23:58.320 に答える
1

アプリケーションは仮想マシンで実行されていますか？

ホストが過負荷またはスワップしているため、VMが機能せず、何かが発生したことを確認できないことが原因である可能性があります。

于 2012-06-22T11:35:30.607 に答える
0

Permanent Generation( PermSize) は、クラス オブジェクトやメソッド オブジェクトなどの VM 自体のリフレクションを保持するために使用されます。これらの反射オブジェクトは、permanent 世代に直接割り当てられ、他の世代とは独立してサイズ設定されます。通常、デフォルトのサイズが適切であるため、この世代のサイジングは無視できます。ただし、多くのクラスをロードするプログラムでは、より大きなパーマネント ジェネレーションが必要になる場合があります。

デフォルトでMaxPermSizeは、-client の場合は 32mb、-server の場合は 64mb です。ただし、 と の両方PermSizeを設定しないとMaxPermSize、必要な場合を除き、全体のヒープは増加しません。と の両方を設定するPermSizeとMaxPermSize、たとえば 192mb のように、追加のヒープ領域が起動時に割り当てられ、割り当てられたままになります。

両方の VM パラメータを調整してみてください。問題が解決する場合があります。

-XX:PermSize=300m -XX:MaxPermSize=300m
于 2012-06-22T11:49:42.290 に答える