SlideShare a Scribd company logo
第六回 #渋谷Java
Java8のJVM監視を考える
2014.5.31
@chonaso
観覧枠が速攻埋まって
たのでLTします
本日のテーマ
• アプリケーションサーバJVMのメモリ監視、
Java8ならどうなるだろうか、を考えました。
• チューニング関係は省略します。
2014.3.18
祝?
Java 8正式リリース
新機能
•ラムダ
• Date-Time API
• タイプアノテーション
• 新JavaScriptエンジン
• JavaFX8
• コンパクトプロファイル
など
そろそろWebアプリでも使う?
• 主要なJavaEEサーバのJava8への本格対応は
まだ微妙?
終了?
∧_∧ / ̄ ̄ ̄ ̄ ̄
[( ・∀・)< JavaEE8頃に起こして
| ̄ ̄ ̄ ̄ ̄ ̄ \_____
| | ̄ ̄ ̄ ̄| |
| | @ @| |
| |@ @ | |
| |____| |
|________|
Java8 JVM的な進化
• メモリ消費の改善
• 階層型コンパイルの標準化
• JITコンパイラの最適化
レガシーコードでもメリットあるかも?
監視メトリクスの
決定的な変更
PermGenの廃止
• PermGen(Permanent Generation)のデメリットを解消
• サイズを決めにくい
• FullGC対象によるパフォーマンスへの影響
らしい。
Metaspace
PermGenに代わる新領域
• ヒープではなくネイティブ領域
• サイズ制限がない(上限設定は可能)
• ガベージコレクタの管理外になるためGCパ
フォーマンスが向上
• Full GC後に拡張/縮小の閾値変更を行う
• アンロードをクラスローダ単位で行う
• 足りない&これ以上拡張できない状態で
OutOfMemoryError
この領域をどう監視する?
引き続き領域サイズと使用量を監視
• よくあるPermGen不足のOutOfMemoryErrorは
起きにくくなりそうだが、原因が解消したわけ
ではない
• メモリの使われ方がPermGenとは違う
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
Compressed Class Space
圧縮OOP(Ordinary Object Pointer)用領域
• Metaspaceの一部
• 64ビット環境でもポインタを圧縮して32ビッ
トで格納する
• 64ビット、最大ヒープサイズ32GB以下で使用
可能(デフォルト?)
• CompressedClassSpace要因のOutOfMemoryError
が発生する。
監視しておいたほうがよさそう
• Metaspace
• デフォルトの最大サイズは無限大(unlimited)
• 初期サイズは指定できない
→サイズが常に変化する
• CompressedClassSpace
• デフォルトの最大サイズは1GB
(いきなり1GB分reserveします)
• 使用量はオブジェクト数・オブジェクトサイズ
(フィールド数)などに依存
• 最大サイズを無限にできない
→不足を検知しないとならない
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
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があったところは空欄
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]
オブジェクト統計情報
• クラス数を調べる
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
ネイティブ観点の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)
~省略~
OSから見たJVM
• CompressedClassSpaceの確保し過ぎによるオー
バーコミット時のOOM Killer発動に注意。
終わり

More Related Content

第六回渋谷Java Java8のJVM監視を考える

Editor's Notes

  1. JavaEE 7への対応すら微妙なものもありますので、Java8でJavaEEはまだ尚早かもしれません。
  2. あってるかわかりませんが、ヒープダンプの大きさはJava7よりJava8の方が10~20%くらい小さかったです。 clientオプションとserverオプションのいいとこ取りをしているとのこと。 アプリケーションサーバの起動が早くなるらしいですが、優位さがわかりませんでした。
  3. サイズ制限がない:ユーザ意識する必要性がない ガベージコレクタの管理外になるためGCパフォーマンスが向上。 アンロードをクラスローダ単位で行うので断片化しない
  4. Ordinary Object Pointer=HotSpotの用語 Compressed Oops ・64bitのマシンでもオブジェクトのアドレスを32bitに格納する (64bitはポインタがでかい) ・ヒープのベースアドレスからのオフセットを利用 ・さらにアドレスのLSBを省略(#3bitシフト)
  5. ちなみにinternされたStringはPermanentからヒープに移動しました
  6. Jcmdはいろいろ見れる