Metaspace拡張によるFGCのチューニングのまとめを1回記録

3841 ワード
開始前
始める前に、私が出会ったjvmチューニングの穴を記録します.それは...
なぜ私はidea 64 exeに配置するのか.vmoptionsのパラメータは有効ではありませんか??
これまでmacで開発されていたため、ローカル開発時にjvmパラメータを最適化する必要がある場合はideaのインストールディレクトリに直接行ってideaを修正する.vmoptionsでいいです.windowsに変えてからも当然だと思いますが、私が構成したパラメータが有効ではないようです.what's the f***?探索してやっと問題の所在を発見した.
Windowsはユーザーログインに基づいており、ideaは各ユーザーに対して現在のユーザールートディレクトリの下に構成情報を作成するので、ideaインストールディレクトリの下でideaを変更する.vmoptionsは有効ではありません.図のように:
管理者ユーザーがログインすると、ideaインストールディレクトリのideaexeを直接変更できるかどうか分かりません.vmoptionsです.現在のideaプロジェクトで使用されている構成情報を簡単に判断する方法があります.
問題を発見する
OK、今やっと私たちのjvmパラメータを最適化することができます.次は私がよく使っているパラメータです.私が以前開発したときは基本的にこのパラメータを使っていました.私もidea 64 exeに直接コピーしました.vmoptions. 
-Xms1024m
-Xmx1024m
-Xmn512m
-XX:MetaspaceSize=256m
-XX:MaxMetaspaceSize=256m
-XX:ReservedCodeCacheSize=512m
-XX:+UseConcMarkSweepGC
-XX:SoftRefLRUPolicyMSPerMB=50
-ea
-Dsun.io.useCanonCaches=false
-Djava.net.preferIPv4Stack=true
-XX:+HeapDumpOnOutOfMemoryError
-XX:-OmitStackTraceInFastThrow

保存してideaを再起動した後、プロジェクトを開いて、うん、何も感じなくて、すべて正常です.2つのプロジェクトを開いて、うん、どうして少しカードがありますか.また1つのプロジェクトを開いて、悪夢が始まって、ideaは爆カードを始めて、カード2 sのあのようなを注文します.
特定の理由
  • jps:idea platformのプロセスID
    • を表示
  • jstat-gcutil pid 3 s:プロセスごみ回収状況の表示
    • 上図から分かるように、最初はYGCもFGCも元気だったが、私が開いているプロジェクトが多くなるにつれて、FGCが急上昇し始め、ページの明らかなカートンを直接招いた.いくつかのプロジェクトを消してみたが、1つだけ残して、FGCは徐々に小さくなってきた.上図を分析すると、Mの割合はFGCがやや下がるにつれて93.7%から93.2%前後に下がった.Metaspace拡張によるFGCの可能性が推測される.
    原因の確認
    jstat-gc pid 3 s:metaspaceの具体的な使用状況を見ることができ、下の図からmetaspaceが拡張されていることがわかります.
    より簡単には、jvisualvmをコマンドしてJava VisualVMを開き、mataspaceの使用サイズを確認します.
    やはり、複数の項目を同時に開くとmetaspaceが拡張され、最終的にmataspaceの使用量は250 M近くに達し、上記の私が構成したパラメータ-XX:MetaspaceSize=256 mにほぼ達したので、上記の構成のmataspaceに関するパラメータを削除しました.
    -Xms1024m
-Xmx1024m
-Xmn512m
-XX:ReservedCodeCacheSize=512m
-XX:+UseConcMarkSweepGC
-XX:SoftRefLRUPolicyMSPerMB=50
-ea
-Dsun.io.useCanonCaches=false
-Djava.net.preferIPv4Stack=true
-XX:+HeapDumpOnOutOfMemoryError
-XX:-OmitStackTraceInFastThrow

    再度jstat-gcutil pid 3 sでGC状況を確認します.
    今回のFGCは状況が大きく改善され、私が開いたプロジェクトが多くなるにつれて、FGCも6回から8回に上昇しただけです.これで、問題は基本的に解決しましたが、それだけなら、私がこのノートを書く意味はあまりありません.次のことがポイントです.
    深く探究する.
    mataspaceのパラメータを再追加してみました.以下のようにします.
    -Xms1024m
-Xmx1024m
-Xmn512m
-XX:MetaspaceSize=384m
-XX:MaxMetaspaceSize=384m
-XX:ReservedCodeCacheSize=512m
-XX:+UseConcMarkSweepGC
-XX:SoftRefLRUPolicyMSPerMB=50
-ea
-Dsun.io.useCanonCaches=false
-Djava.net.preferIPv4Stack=true
-XX:+HeapDumpOnOutOfMemoryError
-XX:-OmitStackTraceInFastThrow

    再度jstat-gcutil pid 3 sでGC状況を確認する:
    上の図は私が同時に5つのプロジェクトを開いたGCの場合、FGCは1回しかないので、これこそ私を困惑させたところです.つまり私がMetaspaceSize=384 mを設置したときと設置しなかったときとでは違います.ネット上でmataspaceに関する文章をたくさん見て、私は自分がずっと-X:MetaspaceSize=256の本当の意味を理解していないことに気づきました.この構成の意味は、初期化メタデータ領域の大きさが256 mではなく、FGCをトリガする閾値を表すだけで、構成と非構成の違いは明らかで、この知識点は本で見たことがあるが気にしていないので、実際に問題にぶつかったときにやっと悟った.
    Metaspaceは-XX:MetaspaceSizeパラメータで指定した量まで拡張し続けるため、FGCが発生します.その後、Metaspace拡張のたびにFGCが発生する可能性があります.
    Metapsaceはjdk 8に導入されたことを知っています.以前はpermGenと呼ばれていました.私たちが言った永久世代です.jdk 8以前は、-XX:PermSize=256 mを構成していました.つまり、256 mのメモリを永続世代として初期化しました.しかしmataspaceは違います.明らかにmataspaceはpermよりずっと高級です.
    まとめ
  • -XXX:MetaspaceSizeが構成されていない場合、FGCをトリガするしきい値は21807104(約20.8 m)である.
  • -XXX:MetaspaceSizeが構成されている場合、FGCをトリガするしきい値が構成の値となります.
  • 配置は配置しないよりよくて、実際に開発する時、先にいくつかのプロジェクトを開いてmetaspaceが大体どれだけのメモリを占有するかを見ることができて、これはプロジェクトの大きさと複雑さと関係があって、更に実際の情況によって-XX:MetaspaceSizeを配置します.

    • 現在のjavaプロセスを表示します.通常、プロセスID(PID)を検索します.
  • jps:現在のjavaプロセスおよびPID
    • を表示
  • jps-l:出力主クラスまたはjarの完全パス名
  • jps-v:出力jvmパラメータ
    • gcの状況を動的に表示
  • jstat-gc pid 3 s:現在のpidプロセスのスタックメモリ詳細
    • を3 sおきに印刷する.
  • jstat-gcutil pid 3 s:現在のpidプロセスのスタックメモリ全体GC統計
    • を3 sおきに印刷する.
    ビジュアル化ツールjvisualvmコマンドライン直接入力jvisualvmビジュアル化ツールを開きjavaプロセスの内部詳細を動的に表示
    以上の3つの方法を組み合わせてjavaプロセスの詳細な使用状況とGC状況を表示できます.
    Pythonのanydbmテンプレートとshelveテンプレートの使用ガイド
    会議の記録