0

Solaris 10 を実行しているお客様が、Permanent GC の容量を 50% から 97% に増やしていることに気付きました。この JVM はデフォルト値の「permgen」を使用していました (カスタム Permgen FLAG を JVM に渡しませんでした)。

本番環境で 97% の permgen スペースで実行する代わりに、より高い値の PermGen を設定する必要がありますか?

PS:solaris 10 で JDK 1.6.0_23 を使用しています。

更新 すぐに OutOfMemoryError が発生する可能性があると考えるべきですか? または、使用率が 97% を下回るように JVM が容量を増やす可能性はありますか?

4

6 に答える 6

2

使用されるPermGenスペースは、アプリケーションコード、または使用しているライブラリの特定のメモリリーク/バグに時間とともに増大する可能性があります。

たとえば、Webアプリケーションインスタンスが何度もリロードされる場合にSpringとlog4jを使用するApache TomcatでWebアプリケーションを実行すると、問題が頻繁に発生します。明らかに、log4jには、クラスローダーから特定のクラスを適切にアンロードしないという問題があります。

そうです、通常のメモリリークと同じように、PermGenスペースが時間の経過とともに増大する原因となるリークが発生する可能性があります。

于 2011-03-25T13:33:22.150 に答える
2

PermGen は、あらかじめ決められた最大値 (コマンド ラインから設定できます) まで成長した後、停止します。PermGen 領域は主にクラス定義を保持します。多くのクラスをロードしてリリースしないアプリケーションでは通常、PermGen が不足します。クラスが大きいためか、Web アプリで何かが誤って保持されているためです。クラスローダがリリースされた後のクラスに。PermGen が成長し続けているのか、それとも最終的に安定しているのかを判断する必要があります。

于 2011-03-25T13:30:19.357 に答える
1

Solaris 10 を実行しているお客様が、Permanent GC の容量を 50% から 97% に増やしていることに気付きました。

perm gen の急増に気付く前に、顧客のアプリケーションに大幅なコード変更がありましたか? それとも、いつもこのような状態でしたか (50% から 97% へ)?

現時点ではそれほど問題ではないと思いますが、場合によっては、このようなスパイクがシステム テスト中に検出されるはずです (チームが顧客のシステム テスト サイクルを把握していると仮定します)。

確かなことの 1 つは、97% で実行することは、快適さのために最大値に近すぎることです。また、max perm gen パラメータをいじる必要があります (結果として、他のヒープ パラメータを使用する可能性が最も高くなります)。

この JVM はデフォルト値の「permgen」を使用していました (カスタム Permgen FLAG を JVM に渡しませんでした)。

良い考えではありません。展開する前に、常にアプリケーション (または顧客) の特性を明らかにする必要があります (必ず読む必要があります)。顧客が必要なパラメーターを伝えるか、チームが UAT およびシステム テスト サイクル中にそれらを決定する必要があります (それらを可視化できると仮定します。上記を参照してください)。

すぐに OutOfMemoryError が発生する可能性があると考えるべきでしょうか?

これは避けられないことではありませんが、可能性はあります (特にアプリがまだ最大負荷にさらされていない場合)。また、スパイクが最近の現象である場合にも発生する可能性があります。その場合、ほとんどの場合、コードの変更、または他の要因 (OS のパッチ、コンテナーのパッチ、顧客トラフィックの変更、データベースの変更など) による未知の状態が原因です。

本番環境で 97% の permgen スペースで実行する代わりに、より高い値の PermGen を設定する必要がありますか?

IMO はい。あなた (またはあなたの顧客) がアプリのメモリ (perm と heap の両方) の要件 (および現在および将来のトラフィック) を特徴付けたり推定したりできる場合は、念のため 10% から 20% のマージンを自分自身に与える必要があります。それ以下はただの火遊びです。それ以上のものは無駄になります。

メモリは安いかもしれませんが、アプリケーションのパフォーマンスと安定性はそうではありません;)

visualgc を使用していない場合は、使用する必要があります。これは、JVM メモリ内のさまざまなセグメントで何が起こっているかを視覚的に検査するための優れたツールです。より強力で用途の広い visualvm もありますが、読み値の visualgc UI プレゼンテーションは、このタスクに特に適しています。

PS:solaris 10 で JDK 1.6.0_23 を使用しています。

それは問題ではないと思います。アプリケーション コンテナーは何ですか (アプリがコンテナーで実行されている場合)。これを含めるように投稿を編集することをお勧めします。

于 2011-03-25T13:47:04.353 に答える
1

私は、JVM が permgen ヒープを拡張するために、通常のヒープの場合と同じ戦略を使用すると信じています。

  • permgen ヒープ サイズは、構成可能な初期サイズから始まります
  • permgen ヒープ サイズに対する使用済み permgen ヒープの比率が、permgen 収集後に指定された値よりも大きい場合、それは拡張されます。
  • permgen ヒープ サイズは、構成可能な最大サイズまで大きくなる場合があります

permgen ヒープが GC 後に 97% いっぱいになっている場合は、permgen が構成された最大サイズ (この場合のデフォルト) にすでに拡張されている可能性が非常に高くなります。

OOME が差し迫っている場所を特定することは不可能です。(アプリケーションの動作方法と、permgen の使用を増加させる原因によって異なります。) ただし、次のことを行うのが賢明です。

  • permgen ヒープの最大サイズを短期的に大きくする。
  • permgen ヒープ使用量の増加の原因を突き止めます。
于 2011-03-25T14:53:03.203 に答える
1

あなたの推論は少し不明確です。

失敗が予想される場合は、防御的なアプローチを取り、-XX:MaxPermSizeすぐに増やしてみませんか?

于 2011-03-25T13:29:33.277 に答える
0

最大 PermGen サイズがあり、この si に達すると OutOfMemoryError が発生します。ただし、97% 使用されている場合でも、その時点で割り当てられているスペースの 97% が最大であることを意味するわけではありません。(別の 3% では、可能であればスペースを拡大する必要があります)

于 2011-03-25T13:45:09.517 に答える