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