スループット コレクター (ParallelGC) を使用しており、ParallelOld も有効にしている-XX:+CMSClassUnloadingEnabledため、使用されていません (これは ConcurrentMarkSweep コレクターで使用されるフラグであるため、単純な CMS フェーズの実行時に Permanent/Metaspace からクラスをアンロードする代わりに、不要な FullGC を待ってい
ます) クライアント マシン、OS、空き RAM の量、CPU/コアの数、クライアント マシンで実行されている Java プロセスの数を教えてください。
Java は決してスワップアウトしないでください。
巨大で静的なヒープ ダンプのリストを収集する代わりに、PrintGC オプションを使用してコレクターの動的な動作のトレースから始めてください。リークが疑われる場合は、jmap -histo:live を使用して ascii ヒストグラムを出力するインスタンス数の増加を確認してください。 (ヒストグラムを収集する前に FullGC を実行します)
ParallelGC は古い世代の Full GC で動作しているため、これは予期される動作です。
どの OutOfMemory を取得しますか? それはヒープにあるか、永続的か、直接的ですか? あなたのフラグのために、私はヒープにいると思います。
どのセグメントがいっぱいになっているかを理解し、それを cleint マシンの限界まで増やしてください。プロセス番号とタイムスタンプを含む gc.log を生成するには、次を使用します。
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:$CATALINA_HOME/logs/gclog_%p_%t.log
追加することもできます-XX:+PrintTenuringDistribution, to see if promotion is done too early, when age of objects is too low. It could be that new size is too small, so should use a bigger new generation with -Xmn
も使用して、各 XX フラグの現在の値を理解できます-XX:+PrintFlagsFinal。http://www.oracle.com/technetwork/articles/java/vmoptions-jsp-140102.htmlも参照してください。
現在の世代サイズで Java 8u102 を開始し、必要に応じてサイズを増やします。
-Xms2048m -Xmn768m -Xmx2048m -XX:MetaspaceSize=512m -XX:MaxMetaspaceSize=512m -XX:MaxDirectMemorySize=2048m -XX:+UseParallelOldGC -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintTenuringDistribution -Xloggc:$CATALINA_HOME/logs/gclog_%p_%t.log <br><br>
<br>
For java 7, instead of Metaspace use Permanent: -XX:PermSize=512m -XX:MaxPermSize=512m
フィードバックが必要な場合は、クライアント マシンと gclog に関するすべての情報を提供してください。
自分で gclog からチューニングを行い、小さすぎると思われるメモリ セグメントを数倍に増やしても、同じ OutOfMemory が引き続き発生する場合は、ParallelGC が FullGC と連携するため、アプリケーションでメモリ リークが発生する可能性があります。 （リリースされたすべてのオブジェクト/クラス/文字列を消去する必要があります）
