JVMパラメータチューニング例の分析

元のソース:

JVM パラメータのチューニングに関しては、多くのプログラマーにとって頭の痛い問題です。設定が適切でない場合、JVM はフル GC を実行し続けるため、システム全体と Web サイトが非常に遅くなります。これが数分おきに続くと、耐えられなくなります。

この種の停滞は、Web サイトの pv が 1 日あたり数十万に達した場合にのみ明らかになります。JVM パラメータを設定するには、若い世代、古い世代、レスキュー スペースを理解する必要があります。永続世代についてある程度の理解があり、JVM メモリ管理ロジックも理解し、最終的には独自のアプリケーションに応じて調整を行う必要があります。インターネットで検索すると、多くの JVM パラメータが見つかります。私もさまざまな例をテストしましたが、数か月の練習と改善を経て、最終的には問題が発生します (要件は必要ありません)。 ) デッドタイムなどの jvm パラメータのチューニングについては、次のような経験があります。

1: Linux での 64 ビット JDK は 32 ビット JDK よりも低速ですが、より多くのメモリを消費し、スループットが高くなります。

2: XMX と XMS の設定は同じサイズであり、MaxPermSize と MinPermSize の設定も同じサイズであるため、ヒープ サイズのスケーリングによって生じる負荷を軽減できます。

3: デバッグ中に、-XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:log/gc.log などの印刷パラメーターを設定して、gc から表示できるようにします。ログ いくつかの手がかりを考え出します。

4: システムが一時停止した場合、GC の問題またはプログラムの問題である可能性があります。Jmap と Jstack を使用して確認するか、killall -3 Java を使用して Java コンソール ログを確認すると、多くの問題が確認できます。あるとき、Web サイトが突然非常に遅くなったので、Jstack を調べたところ、自分で作成した URL 接続が多すぎて解放されていないことがわかり、プログラムを変更したところ、問題なくなりました。

5: アプリケーションを注意深く理解してください。キャッシュを使用する場合は、キャッシュされた HashMap が無限に長くならないようにする必要があります。LRUMap の最大長も使用することをお勧めします。実際の状況に基づいて設定されています。

6: 昇格の失敗は、ガベージ コレクション中に発生する非常に厄介な問題です。一般に、最初の理由は、レスキュー スペースが不十分であることです。 2 番目の理由は、古い世代には若い世代からのオブジェクトを受け入れるための十分なスペースがないため、どちらの場合もフル GC になります。ウェブサイトの一時停止時間が長くなります。 1 番目の理由に対する最終的な解決策は、レスキュー スペースを削除し、-XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0 を設定することです。2 番目の理由に対する私の解決策は、CMSInitiatingOccupancyFraction を特定の値 (70 と仮定) に設定することです。 , CMS は、古い世代のスペースが 70% に達すると実行され、古い世代には若い世代からのオブジェクトを受け入れるのに十分なスペースが確保されます。

7: 永続世代は徐々にいっぱいになるため、Java サーバーを 3 ～ 5 回ごとに再起動する必要があります。私は毎日自動的に再起動します。

8: 同時リサイクルを使用する場合は、若い世代を小さくし、古い世代を大きくする必要があります。古い世代は同時リサイクルを使用するため、時間がかかっても他のプログラムの継続的な動作には影響しません。ウェブサイトは一時停止しません。 私の最終的な結果は次のとおりです (システム 8G メモリ)、毎日何百万もの PV が問題なく表示され、ウェブサイトは停止せず、2009 年にメモリの問題でウェブサイトがダウンすることはありませんでした。

2. $JAVA_ARGS .= " -Dresin.home=$SERVER_ROOT -server -Xms6000M -Xmx6000M -Xmn500M -XX:PermSize=500M

4. -XX:MaxPermSize=500M -XX :SurvivorRatio=

   65536 -XX:MaxTenuringThreshold=0 -Xnoclassgc -XX:+DisableExplicitGC

6. -XX:+UseParNewGC -XX:+UseConcMarkSoupGC -XX: +UseCMSCompactAtFullCollection

8. -XX:CMSFullGCsBeforeCompaction=

   0 -XX:+CMSClassUnloadingEnabled -XX:-CMSParallelRemarkEnabled

10. -XX:CMSInitiatingOccupancyFraction=

    90 -XX:Soft RefLRUPolicyMSPer MB=0 -XX:+PrintClassHistogram

-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:log/gc.log ";

13. 説明、-XX:SurvivorRa=65 536 - XX:MaxTenuringThreshold=0 は、レスキュー スペースが削除されることを意味します。

◆-Xnoclassgc はガベージ コレクションを無効にし、パフォーマンスが向上します。

◆-XX:+DisableExplicitGC は、プログラマーが誤って呼び出しを防ぐために System.gc() を無効にします。 gc メソッドとパフォーマンスに影響を与える;
◆-XX:+UseParNewGC は、若い世代向けにマルチスレッドの並列リサイクルを使用するため、CMS パラメーターは同時リサイクルに関連します。


CMS占有率の開始

このパラメータの設定には多くのスキルが必要です。基本的に、(Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)/100>=Xmn の場合、昇格は失敗しません。私のアプリケーションでは、Xmx は 6000、同時ガベージ コレクション (CMS) では、この時点での残りの 10% のスペースは 5500*10%=550 MB であるため、Xmn 内のすべてのオブジェクト (つまり、合計 500 MB) があったとしても、若い世代) は古い世代に移動されます (550 MB) 十分なスペースがあるため、上記の式が満たされている限り、ガベージ コレクション中に昇格失敗は発生しません

SoftRefLRUPolicyMSPerMB

このパラメーターは可能だと思います。公式の説明では、ソフト到達可能なオブジェクトは、最後に参照されてから一定時間存続するということですが、デフォルト値はヒープ内の空きメガバイトごとに 1 秒です。 1 秒待ってください。

インターネット上には他にも JVM パラメータの紹介がたくさんありますが、そのほとんどは、プロモーション失敗に遭遇したことがないか、アクセス数が少なすぎて遭遇する機会がない場合に発生すると考えられます。 、式 (Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)/100>=Xmn は間違いなくオリジナルです。実際にプロモーション失敗が発生した場合は、この方法で対処する必要があります。

以上がJVMパラメータチューニング例の分析の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。