Slide 1

Size: px

Start display at page:

Download "Slide 1"

あいりひらみね
6 years ago
Views:

1 Oracle Direct Seminar <Insert Picture Here> 高速 JVM Oracle JRockit の全貌入門編

2 Agenda JRockitとは JRockitの内部動作について JRockitの運用監視について 2

3 概要 JRockit とは? BEA(Oracle) が提供 & サポートする Java SE 完全準拠の JVM もともとサーバサイド用途専用に作られた JVM( 現在はクライアントサイド用途にも対応 ) Intel アーキテクチャ (Xeon,Itanium2) へ最適化された業界最速の JVM( 現在は Sparc 版も提供 ) 歴史 1998 年スウェーデンアピールバーチャルマシンより初版がリリース 2002 年 BEA がアピールバーチャルマシンを買収 2008 年 Oracle が BEA を買収 Sun J2SE との互換性 java version でベースとなる Sun J2SE のバージョンを表示 R27.5 java version "1.5.0_14" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_14-b03) BEA JRockit(R) (build R _ windows-ia32, compiled mode) R27.6 java version "1.5.0_15" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_15-b04) BEA JRockit(R) (build R _o _ windows-ia32, compiled mode) JRockit に含まれる各種ツール JavaAPI は基本的に J2SE と同一だが J2SE では定義されていない部分 ( ネーティブコード生成最適化メモリ管理独自ツール等 ) を BEA が固有実装 3

レスポンスタイム (ms) オンメモリで自動記録 JRockit Java SE 完全準拠の高機能 JVM 高速 : サーバーサイド用途に最適化

予測外の事態でも過去に遡って分析可能 #1 パフォーマンス ( 高速 ) 公式ベンチマーク (SPECjbb) 処理性能数値の世界最高値 JVM

GC を JVM で制御 ( 安定 ) JRockit VM 1 0 1 0 0 0 0 1 1 1 1 1 0 1 0 破棄 Time 300 300 250

4 レスポンスタイム (ms) オンメモリで自動記録 JRockit Java SE 完全準拠の高機能 JVM 高速 : サーバーサイド用途に最適化公式ベンチマークで実証済み安定 : GC による遅延時間の平準化ミリ秒単位の応答時間の維持を実現全てを記録 : 稼動状況を常に記録予測外の事態でも過去に遡って分析可能 #1 パフォーマンス ( 高速 ) 公式ベンチマーク (SPECjbb) 処理性能数値の世界最高値 JVM あたりの性能数値の世界最高値 WebLogic Server 性能を犠牲にすることなく全ての挙動を記録実行時情報不測の GC 処理処理の滞留タイムアウト GC を JVM で制御 ( 安定 ) JRockit VM 破棄 Time 通常 JVM JRockit Real Time 設定された時間枠 ( 例 : 前 5 分間 ) の稼動情報をオンメモリで常時保持何か起きても過去に遡って分析可能 4

5 JRockit の特長 - The Server Side Java VM - サーバサイド Java の特徴と要求特徴マルチプロセッサマシンでの利用長時間稼動大きなメモリヒープサイズ Synchronizationの多用動的なクラスローディングの多発小さい単位の処理を多くのスレッドで並行実行ソケット通信やファイルI/Oの多用要求高信頼性可用性 / 管理性拡張性性能クライアントサイドでの Java の利用とは異なった特徴と要求 5

6 JRockit の特長 - The Server Side Java VM - Java VM 処理の比重 CG = Code Generation クライアントサーバ MM = Memory Management TM = Thread Management MM R TM IO R CG I/O R = Reflection CG MM TM クライアントとは異なるサーバサイドの処理要求に特化した Java VM が必要 6

7 JRockit の特長 - 高速性 - Higher performance leads to significant cost savings 公式ベンチマークで証明された高速性 SPECjbb2005 トップ 10 のうち 6 つが JRockit (Last publication update: Jun ) 7

8 Agenda JRockitとは JRockitの内部動作について JRockitの運用監視について 8

9 そもそも JVM とは? Java ソースコードバイトコード配布実行コンパイル中間コード JVM JVM JVM JVM JVM Solaris HP-UX AIX Linux Windows Any Hardware ランタイム OS ハードウェア JVM(Java Virtual Machine) Java プログラムの実行環境 - バイトコードを 1 行ずつ機械語 (machine code) に変換し実行 - 各 OS の機能を覆い隠す役割も担う 9

10 JRockit アーキテクチャ ~ ネーティブコード生成 ~ Sun JVM の場合バイトコードのままインタープリタで実行メソッドの実行回数を常時監視実行回数が閾値 (-XX:CompileThreshold) を超えたメソッドをコンパイルしてネーティブコードを生成 byte code インタプリタ実行 1 メソッド実行回数監視 2 コンパイル 3 native code ネーティブ実行 JRockit の場合各メソッドの初回実行時にバイトコードをJITコンパイルしてネーティブコードを生成バックグランドで動くサンプルスレッドが定期的にアプリケーションスレッドの状態を監視し頻繁に使用されているメソッドをリストアップまだ最適化されていないメソッドのうちで最も使用頻度が高いメソッドをより高速なネーティブコードへ最適化 byte code JIT コンパイル native code アプリスレッド監視最適化 native code+ 1 ネーティブ実行 2 3 ネーティブ実行 10

11 コード最適化を示す例最適化されたコードではクラス A を実行するたびにクラス B を実行する必要がない 11

12 JRockit アーキテクチャ ~ スレッドローカルエリア (TLA)~ TLA が無いと各スレッドはオブジェクトをアロケートするたびにヒープのロックを得る必要があるので遅い Thread 1 Thread 2 Thread 3 a = new Object(); b = new Object(); c = new Object(); Heap lock TLA が有れば各スレッドの専用エリアにオブジェクトをアロケートできるので速い ( もちろんアロケート済みオブジェクトは他スレッドからも利用可能 ) Thread 1 Thread 2 Thread 3 a = new Object(); b = new Object(); Heap lock c = new Object(); TLA for Thread 1 TLA for Thread 2 TLA for Thread 3 TLA for Thread 1 12

13 JRockit アーキテクチャ ~ メモリレイアウト ~ Java のオブジェクトは Sun JVM でも JRockit でもヒープに置かれる Java のクラスは Sun JVM では Permanent 領域 JRockit では Native 領域に置かれる JRockit では Sun JVM における Survivor(From&To) に相当する領域は無く Nursery がフルになると Old にすぐに昇格するよって JRockit では初回 GC で生き残ったオブジェクトは全て以降は Full GC のチェック対象になるが Full GC が発生しても問題ないような様々な工夫がされている JRockit では高速化等を目的に Sun JVM には無い様々な情報が Native 領域に置かれる Sun JVMの場合ヒープ New Eden Survivor From To Xmn Xmx/Xms JRockit の場合ヒープ Nursery 0 1 Xns Xmx/Xms Old Old 最大 32 回でプロモーション Perm anent Native -XX:PermSize -XX:MaxPermSize 1 回でプロモーション Native 13

14 ご参考 Parallel GC と Concurrent GC 従来の GC では GC を一つのスレッドで実行しその間アプリケーションスレッドは停止 (STOP-THE-WORLD) していましたそのためマルチ CPU マシンで GC の間待機する CPU が存在しスループットが低下する原因となりましたこれへの対策が GC を複数スレッドで実行するパラレル GC アプリケーションを止めずに GC を 1 スレッドで実行するコンカレント GC です従来の GC STOP-THE- World!! Parallel STOP-THE-World!! Concurrent CPU に処理が割り当てられず性能が低下 14

15 JRockit ガーベッジコレクション 1 Parallel Garbage Collection (for New GC and Old GC) JVM は 1CPU あたり 1GC スレッドを並列に使用して一気に GC を行う GC の間はアプリケーションスレッドは完全に止まるがトータルでのアプリケーションのスループットは最も高くなる Java application threads Garbage Collector threads 15

16 JRockit ガーベッジコレクション 2 Mostly Concurrent Garbage Collection (for Old GC) 1 つの GC 専用のスレッドが GC 処理のほとんどのフェーズをアプリケーションと同時に行う GC 中のアプリケーションのスループットは落ちるものの停止は避けられる Java application threads Garbage Collector thread GC スレッドがヒープ内のオブジェクトの移動と削除を行うときのみ短時間アプリケーションスレッドが止まる 16

17 JRockit アーキテクチャ ~ ガーベッジコレクション ~ ガーベッジコレクション方式の指定方法動的 GC 重視する指針のみを指定し GC アルゴリズムについては JRockit が内部で最適な組み合わせを動的に選択重視する指針アプリケーションのスループット ( デフォルト ) 個々の GC ポーズタイムの短縮アプリのレスポンスタイム (JRockit Real Time でのみ利用可能 ) 指定方法 -XgcPrio:throughput -XgcPrio:pausetime -XpauseTarget=<n>ms -XgcPrio:deterministic - XpauseTarget=<n>ms 17

18 JRockit Real Time 従来の Java では困難だった予測可能なレスポンスを実現 120 従来の Java JRockit Real Time 低トランザクション時 :GC による一部タイムアウトが発生しうる高トランザクション時 : GC による停止によりレスポンスタイムが劣化する JRockit Real Time は Deterministic GC により GC 停止時間を抑制安定したレスポンスを提供アプリケーションに手を入れる必要なし 18

19 Deterministic GC - JRockit Real Time Mostly Concurrent GC をさらに改善 1 世代ヒープ (Nursery と Old 間の参照や移動のコストを削減 ) 個々の PauseTime の制限付け (-XpauseTarget=XXms) ただしあくまで努力目標アプリ特性とヒープ設定によっては守れないこともアプリスレッドを止めなければならない GC のフェーズをパラレル化オブジェクトの生成速度を随時観察し GC のスケジュールを最適化例 ) ヒープ全体を一度に GC するのではなく複数回の短い GC に分割例 ) ヒープが一杯になる前に早めに GC を開始例 ) 開始した GC が予定時間内に終わりそうにない場合に一旦 GC を中止し可能なら残作業を次回 GC に繰り越し Java application threads Garbage Collector threads 19

20 JRockit 動的 GC アルゴリズム別性能比較スループット優先 GC ポーズタイム優先 GC Deterministic GC ポーズタイムスループットレスポンス 20

21 Agenda JRockitとは JRockitの内部動作について JRockitの運用監視について 21

JRockit Mission Control JRockit 専用の GUI ベースの運用監視ツール TCP/IP

側は以下のオプションでポートを開けるだけ ( エージェント等のインストール不要 ) 例 :

Management Console: CPU 使用率ヒープ使用状況スレッド使用状況 MBean 監視 Memory

22 JRockit Mission Control JRockit 専用の GUI ベースの運用監視ツール TCP/IP ベースのプロトコルでリモートの JRockit プロセスの運用監視が可能監視される JRockit 側は以下のオプションでポートを開けるだけ ( エージェント等のインストール不要 ) 例 : -Xmanagement:port=7091,ssl=false,authenticate=false 機能一覧 Management Console: CPU 使用率ヒープ使用状況スレッド使用状況 MBean 監視 Memory Leak Detector: 迅速なメモリリーク検出オブジェクトの参照関係の階層表示 JRockit Flight Recorder: GC 詳細情報ホットパッケージホットメソッド情報 22

メソッドプロファイリング Management Console のオーバヘッドは非常に小さくほとんど無視できる程度大部分の情報は JRockit 特有の MBean

23 Management Console リアルタイムに JVM の内部情報を取得 CPU 使用状況 (JVM/Machine) メモリ使用状況 (JVM/Machine) をグラフ表示任意の MBean 情報の閲覧更新グラフ化トリガアラートの設定スレッド情報 ( スタックトレース CPU ビジーデッドロック有無 ) の確認メソッドプロファイリング Management Console のオーバヘッドは非常に小さくほとんど無視できる程度大部分の情報は JRockit 特有の MBean として常時更新されているため但し監視対象の JRockit と同一マシンでの Management Console 起動は GUI 負荷が高くなるため推奨しない 23

24 Memory Leak Detector メモリーリーク監視診断機能稼働中の JRockit プロセスに接続してリアルタイムに傾向を取得サンプル中の Object 増加数サイズインスタンス数ヒープ中における割合各 Object を参照している Object スタックを階層的に表示が可能ガベージコレクションのマークフェーズを巧みに利用してヒープ上のクラス別メモリ統計情報を取得しているためオーバヘッドがほとんどなく監視可能 (JVM 開発ベンダーだからこそ可能な方法 ) 24

JRockit Flight Recorder 突然のトラブルに対する新アプローチ 2010.07 New Release! as JRockit (R28) with WebLogic 10.3.3 これまでの Java Java EE/ISV アプリ App Server JVM ダンプを解析 Full thread dump Java HotSpot(TM) Client VM (1.5.

25 JRockit Flight Recorder 突然のトラブルに対する新アプローチ New Release! as JRockit (R28) with WebLogic これまでの Java Java EE/ISV アプリ App Server JVM ダンプを解析 Full thread dump Java HotSpot(TM) Client VM (1.5.0_06-64 mixed mode, sharing): "Low Memory Detector" daemon prio=5 tid=0x0050a600 nid=0x1816a00 runnable [0x x ] "CompilerThread0" daemon prio=9 tid=0x00509cb0 nid=0x waiting on condition [0x xf0b06358] "Signal Dispatcher" daemon prio=9 tid=0x nid=0x waiting on condition [0x x ] "Finalizer" daemon prio=8 tid=0x nid=0x in Object.wait() [0xf0a xf0a04ab0] at java.lang.object.wait(native Method) - waiting on <0x > (a java.lang.ref.referencequeue$lock) at java.lang.ref.referencequeue.remove(referencequeue.java:116) - locked <0x > (a java.lang.ref.referencequeue$lock) at java.lang.ref.referencequeue.remove(referencequeue.java:132) at java.lang.ref.finalizer$finalizerthread.run(finalizer.java:159) "Reference Handler" daemon prio=10 tid=0x00508c30 nid=0x180f200 in Object.wait() [0xf xf0983ab0] at java.lang.object.wait(native Method) - waiting on <0x26580a50> (a java.lang.ref.reference$lock) at java.lang.object.wait(object.java:474) at java.lang.ref.reference$referencehandler.run(reference.java:116) - locked <0x26580a50> (a java.lang.ref.reference$lock) "main" prio=5 tid=0x005013a0 nid=0x1804c00 waiting on condition [0xf07ff000..0xf08002c0] at java.lang.thread.sleep(native Method) at ThreadTest1.method1(ThreadTest1.java:7) at ThreadTest1.main(ThreadTest1.java:4) "VM Thread" prio=9 tid=0x nid=0x1803c00 runnable "VM Periodic Task Thread" prio=9 tid=0x0050bcb0 nid=0x waiting on condition "Exception Catcher Thread" prio=10 tid=0x005015e0 nid=0 JRockit Flight Recorder Java EE/ISV アプリ Oracle WebLogic Server JRockit VM 直近 ( 例 : 24 時間 ) の実行時情報を記録し続ける自動記録 5% 以下の低負荷問題解決に必要な情報の多くは消失原因究明に多くの時間が必要履歴を含めた情報を記録し自動出力迅速な原因究明を支援する GUI ツール 1. トラブルの確実な原因追究を遡って実施可能 2. 障害発生改善のサイクルと手間を大きく短縮化 25

26 26

27 27

28 28

29 JRockit 診断コマンド ~jrcmd~ 同一マシン上で稼働中の JRockit インスタンスに対してコマンドを発行して JRockit 内部の様々な情報を得たり動作設定を変更することが可能 jrcmd <pid> <command> 主要コマンド start_management_server kill_management_server startjrarecording stopjrarecording print_object_summary print_class_summary print_threads print_memusage runsystemgc verbosity help JRMCポートを開ける JRMCポートを閉じる JRAレコーディングを開始 JRAレコーディングを停止クラス別インスタンス数 / メモリ使用量など表示クラスロードされているクラスを全て表示スレッドダンプを表示メモリ領域 (Heap/Nativeなど) ごとの使用状況表示 Full GCを強制実行冗長ログの出力項目 / 出力先の変更使用可能なコマンド一覧各コマンド使用方法 29

30 以上の事項は弊社の一般的な製品の方向性に関する概要を説明するものですまた情報提供を唯一の目的とするものでありいかなる契約にも組み込むことはできません以下の事項はマテリアルやコード機能を提供することをコミットメント ( 確約 ) するものではないため購買決定を行う際の判断材料になさらないで下さいオラクル製品に関して記載されている機能の開発リリースおよび時期については弊社の裁量により決定されます Oracle PeopleSoft JD Edwards 及び Siebel は米国オラクルコーポレーション及びその子会社関連会社の登録商標ですその他の名称はそれぞれの会社の商標の可能性があります 30

31 31

32 ご参考 GC アルゴリズム概要 JVM 一般マーク & スイープアルゴリズム JRockit を含め多くの Java VM はマーク & スイープアルゴリズムによって GC 対象となるオブジェクトを決定しオブジェクトが利用していたヒープ領域を回収しますオブジェクトの移動 ( コンパクションとプロモーション ) 生存中のオブジェクトがヒープ全体にちらばると空き領域の連続長が短くなりますこれをフラグメンテーションが進んだ状態と呼び大きなオブジェクトの生成時の領域確保に失敗する可能性を秘めています生存中のオブジェクトを移動し十分に連続した空き領域を確保する処理をコンパクションと呼びます特に世代管理されたヒープで世代間に渡ってオブジェクトを移動することをプロモーションと呼びます実際にはオブジェクトの移動はスイープフェーズの一部として行われますが論理的には別フェーズと考える方が単純ですマークフェーズスイープフェーズコンパクション / プロモーションフェーズ 1 回の GC 32 32

33 ご参考マークフェーズ JVM 一般マークフェーズでは全てのスレッド ( ルートセット ) からオブジェクトの参照を辿り参照可能 ( 利用されている ) なオブジェクト全てに利用中マークをつける処理が行われますルートセットスレッド 1 スレッド 2 スレッド 3 スレッド 4 レレレレチェックの付かなかったオブジェクトが GC の対象となるレレレレレレレ 33 33

34 ご参考スイープフェーズ JVM 一般スイープフェーズではヒープを端から走破してマークの付いていないオブジェクトを回収します回収された領域は前後の空き領域と合わせられ空き領域リストとして管理されますヒープ領域レレレレレレレアドレス領域長空き領域リスト 34 34

35 ご参考コンパクションフェーズ JVM 一般コンパクションフェーズでは利用中のオブジェクトを移動 ( 再配置 ) して大きな空き領域を作成しますオブジェクトの移動に伴いそのオブジェクトへの参照も全て書き換えられます JNI で利用されている等 Java VM が参照を全て把握できないオブジェクトは移動できずピンドオブジェクトと呼ばれますヒープ領域コンパクション 35 35

<Insert Picture Here> Oracle ユーザーのための WebLogic 入門日本オラクル株式会社製品事業統括 Fusion Middleware 事業統括本部担当シニアマネージャ新井庸介

<Insert Picture Here> Oracle ユーザーのための WebLogic 入門日本オラクル株式会社製品事業統括 Fusion Middleware 事業統括本部担当シニアマネージャ新井庸介 Oracle ユーザーのための WebLogic 入門日本オラクル株式会社製品事業統括 Fusion Middleware 事業統括本部担当シニアマネージャ新井庸介以下の事項は弊社の一般的な製品の方向性に関する概要を説明するものですまた情報提供を唯一の目的とするものでありいかなる契約にも組み込むことはできません以下の事項はマテリアルやコード