Submit Search
第六回渋谷Java Java8のJVM監視を考える
•
Download as PPTX, PDF
•
24 likes
•
15,502 views
C
chonaso
Follow
1 of 22
Download now
Downloaded 30 times
More Related Content
第六回渋谷Java Java8のJVM監視を考える
1.
第六回 #渋谷Java Java8のJVM監視を考える 2014.5.31 @chonaso
2.
観覧枠が速攻埋まって たのでLTします
3.
本日のテーマ • アプリケーションサーバJVMのメモリ監視、 Java8ならどうなるだろうか、を考えました。 • チューニング関係は省略します。
4.
2014.3.18 祝? Java 8正式リリース
5.
新機能 •ラムダ • Date-Time API •
タイプアノテーション • 新JavaScriptエンジン • JavaFX8 • コンパクトプロファイル など
6.
そろそろWebアプリでも使う? • 主要なJavaEEサーバのJava8への本格対応は まだ微妙?
7.
終了? ∧_∧ / ̄ ̄ ̄ ̄ ̄ [( ・∀・)<
JavaEE8頃に起こして | ̄ ̄ ̄ ̄ ̄ ̄ \_____ | | ̄ ̄ ̄ ̄| | | | @ @| | | |@ @ | | | |____| | |________|
8.
Java8 JVM的な進化 • メモリ消費の改善 •
階層型コンパイルの標準化 • JITコンパイラの最適化 レガシーコードでもメリットあるかも?
9.
監視メトリクスの 決定的な変更
10.
PermGenの廃止 • PermGen(Permanent Generation)のデメリットを解消 •
サイズを決めにくい • FullGC対象によるパフォーマンスへの影響 らしい。
11.
Metaspace PermGenに代わる新領域 • ヒープではなくネイティブ領域 • サイズ制限がない(上限設定は可能) •
ガベージコレクタの管理外になるためGCパ フォーマンスが向上 • Full GC後に拡張/縮小の閾値変更を行う • アンロードをクラスローダ単位で行う • 足りない&これ以上拡張できない状態で OutOfMemoryError
12.
この領域をどう監視する? 引き続き領域サイズと使用量を監視 • よくあるPermGen不足のOutOfMemoryErrorは 起きにくくなりそうだが、原因が解消したわけ ではない • メモリの使われ方がPermGenとは違う
13.
jstat • PC/PUがMC/MU,CCSC/CCSUに変更されている Java7 $ /usr/java/jdk8/bin/jstat
-gc 6516 S0C S1C S0U S1U EC EU OC OU PC PU (略) 2560.0 2560.0 0.0 0.0 30720.0 317.5 36864.0 15032.1 28672.0 14250.7 (略) Java8 $ /usr/java/jdk8/bin/jstat -gc 15802 S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU (略) 4096.0 4096.0 0.0 0.0 32768.0 368.8 14336.0 11029.2 15104.0 14456.5 1792.0 1597.2
14.
Compressed Class Space 圧縮OOP(Ordinary
Object Pointer)用領域 • Metaspaceの一部 • 64ビット環境でもポインタを圧縮して32ビッ トで格納する • 64ビット、最大ヒープサイズ32GB以下で使用 可能(デフォルト?) • CompressedClassSpace要因のOutOfMemoryError が発生する。
15.
監視しておいたほうがよさそう • Metaspace • デフォルトの最大サイズは無限大(unlimited) •
初期サイズは指定できない →サイズが常に変化する • CompressedClassSpace • デフォルトの最大サイズは1GB (いきなり1GB分reserveします) • 使用量はオブジェクト数・オブジェクトサイズ (フィールド数)などに依存 • 最大サイズを無限にできない →不足を検知しないとならない
16.
jcmd • PerfCounter.printで確認 $ /usr/java/jdk8/bin/jcmd
20314 PerfCounter.print | egrep "sun.gc.metaspace|sun.gc.compressedclassspace" sun.gc.compressedclassspace.capacity=1835008 sun.gc.compressedclassspace.maxCapacity=1073741824 sun.gc.compressedclassspace.minCapacity=0 sun.gc.compressedclassspace.used=1635480 sun.gc.metaspace.capacity=15466496 sun.gc.metaspace.maxCapacity=1088421888 sun.gc.metaspace.minCapacity=0 sun.gc.metaspace.used=14783248
17.
jmap • Metaspaceが取れない・・・ $ /usr/java/jdk8/bin/jmap
-heap 20314 ~略~ Heap Configuration: MinHeapFreeRatio = 40 MaxHeapFreeRatio = 70 ~略~ MetaspaceSize = 21807104 (20.796875MB) CompressedClassSpaceSize = 1073741824 (1024.0MB) MaxMetaspaceSize = 17592186044415 MB G1HeapRegionSize = 0 (0.0MB) Heap Usage: PS Young Generation Eden Space: capacity = 31457280 (30.0MB) ~略~ PS Old Generation capacity = 61341696 (58.5MB) used = 10789152 (10.289337158203125MB) free = 50552544 (48.210662841796875MB) 17.58861052684295% used 9376 interned Strings occupying 817192 bytes. Permanentがあったところは空欄
18.
GCログ • 実行後の値をチェック (最大サイズとの比較) 131.758: [Full
GC (Heap Inspection Initiated GC) 131.758: [CMS: 51721K->30733K(122880K), 0.1359317 secs] 86379K- >30733K(307200K), [Metaspace: 31792K->31792K(1077248K)], 0.1360976 secs] [Times: user=0.14 sys=0.00, real=0.14 secs]
19.
オブジェクト統計情報 • クラス数を調べる num #instances
#bytes class name ---------------------------------------------- 1: 87409 11724328 [C 2: 6177 6240016 [B 3: 85545 2053080 java.lang.String 4: 12649 1113112 java.lang.reflect.Method 5: 34677 1109664 java.util.HashMap$Node 6: 26085 1043400 java.util.LinkedHashMap$Entry 7: 3509 699256 [Ljava.util.HashMap$Node; 8: 6415 671104 java.lang.Class 9: 8933 551960 [Ljava.lang.Object; 10: 20576 493824 org.apache.tomcat.util.bcel.classfile.ConstantUtf8 11: 4868 350496 java.lang.reflect.Field 12: 4146 265344 java.net.URL 13: 4501 216048 org.apache.catalina.loader.ResourceEntry 14: 9434 201936 [Ljava.lang.Class; 15: 6079 194528 java.util.concurrent.ConcurrentHashMap$Node 16: 3956 189888 java.util.HashMap 17: 7096 170304 java.util.ArrayList 18: 1987 158960 java.lang.reflect.Constructor
20.
ネイティブ観点のMetaspace • ざっくり数えるならこちらが楽 $ /usr/java/jdk8/bin/jcmd
20314 VM.native_memory 20314: Native Memory Tracking: Total: reserved=2364320KB, committed=189932KB - Java Heap (reserved=978944KB, committed=98816KB) (mmap: reserved=978944KB, committed=98816KB) - Class (reserved=1066401KB, committed=18593KB) (classes #2344) (malloc=3489KB, #2695) (mmap: reserved=1062912KB, committed=15104KB) - Thread (reserved=18580KB, committed=18580KB) (thread #18) (stack: reserved=18504KB, committed=18504KB) (malloc=55KB, #94) (arena=21KB, #36) ~省略~
21.
OSから見たJVM • CompressedClassSpaceの確保し過ぎによるオー バーコミット時のOOM Killer発動に注意。
22.
終わり
Editor's Notes
JavaEE 7への対応すら微妙なものもありますので、Java8でJavaEEはまだ尚早かもしれません。
あってるかわかりませんが、ヒープダンプの大きさはJava7よりJava8の方が10~20%くらい小さかったです。 clientオプションとserverオプションのいいとこ取りをしているとのこと。 アプリケーションサーバの起動が早くなるらしいですが、優位さがわかりませんでした。
サイズ制限がない:ユーザ意識する必要性がない ガベージコレクタの管理外になるためGCパフォーマンスが向上。 アンロードをクラスローダ単位で行うので断片化しない
Ordinary Object Pointer=HotSpotの用語 Compressed Oops ・64bitのマシンでもオブジェクトのアドレスを32bitに格納する (64bitはポインタがでかい) ・ヒープのベースアドレスからのオフセットを利用 ・さらにアドレスのLSBを省略(#3bitシフト)
ちなみにinternされたStringはPermanentからヒープに移動しました
Jcmdはいろいろ見れる
Download