Download SlideShare for Android. 15 million presentations at your fingertips  Get the app
×
  • Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
 
« ‹ › »
   

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

on

  • 152 views

 

Statistics

Views

Total Views
152
Views on SlideShare
120
Embed Views
32

Actions

Likes
1
Downloads
1
Comments
0

3 Embeds 32

http://chonaso.hatenablog.com 30
https://twitter.com 1
http://www.slideee.com 1

Accessibility

Categories

Upload Details

Uploaded via SlideShare as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

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

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

  • 第六回 #渋谷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発動に注意。
  • 終わり