2012年5月9日

<Insert Picture Here>

2 以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。

また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供することをコミットメント（確約）するものではないため、購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。

OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。

文中の社名、商品名等は各社の商標または登録商標である場合があります。

アジェンダ

 JRockit Flight Recorderクイックレビュー

 目的や仕組み

 開始、終了方法

 イベント、テンプレート

 製品ライセンス（重要！）

 JRockit Flight Recorderのユースケース（デモ）

 課題1：ホットスポットを探す

 課題2：レイテンシー調査

 課題3： GCの調査

3 目標

 JRockit Flight Recorderの目的、使用方法を理解し、デモを通じて適用イメージを体感する。

 ステップ1 （クイックレビュー）

 JRokit JVM, JRockit Flight Recorder, イベント、テンプレート、Mission Controlの概要を理解する。

 ステップ2

 JRockit Flight Recorderのデモから活用イメージを体感

4

5 JRockit Flight Recorder クイックレビュー

 目的や仕組み、記録の開始、終了方法

 イベント、テンプレート

 製品ライセンス（重要！）

JRockit JDKとは？

 概要

 Oracleが提供＆サポートするJava SE完全準拠のJava開発・実行環境

 サーバサイド用途専用に設計された高信頼性の JVM

※現在はクライアントサイド用途にも対応

 Intel アーキテクチャ（ Xeon, Itanium2 ）へ最適化された業界最高速の JVM

※現在はSparc版も提供

 歴史

 1998 年スウェーデンアピールバーチャルマシンより初版がリリース

 2002 年 BEA がアピールバーチャルマシンを買収

 2008 年 Oracle が BEA を買収

 Java SE との互換性

 java –version でベースとなる Java SE のバージョンを表示

 JRockit JDKに含まれる各種ツール、ライブラリ（JRE等）は基本的にSun Java VMと同一だが、Java SEでは定義されていない部分（ネーティブコード生成・最適化、メモリ管理、デッドロック検出、管理用コマンド、 GUI ベースの監視ツール等）を固有実装

java version "1.6.0_14"

Java(TM) SE Runtime Environment (build 1.6.0_14-b08)

BEA JRockit(R) (build R27.6.5-32_o-121899-1.6.0_14-20091001-2107-windows-ia32, compiled mode)

java version "1.6.0_20"

Java(TM) SE Runtime Environment (build 1.6.0_20-b02)

Oracle JRockit(R) (build R28.0.1-21-133393-1.6.0_20-20100512-2132-windows-ia32, compiled mode)

R27.6.5

R28.0.1

JRockitのコード生成戦略

 プラットフォーム非依存性を損なわずに高速性を実現

 バイトコードを1ステップずつ毎回解釈しながら実行するインタプリタ方式は低速なのでもとより不採用

 全バイトコードを事前にネーティブコード化するAOT（Ahead-of-time Compilation）方式はプラットフォーム間の移植性を損なうので不採用

 サーバサイドで実行されるアプリケーションの特徴を考慮

 大部分のロジックは静的であり、実行時に変更されることは稀である

 同一のロジックが長時間に渡って繰り返し実行される

 ネーティブコード生成・最適化のコストは、実行時に十分ペイできると判断し、JRockitでは以下の方針を採用

 初回実行時にネーティブコードを生成

 実行時統計からのフィードバックをもとにネーティブコードをさらに最適化

7 JRockitのGCモードの選択におけるトレードオフ

8

△動作モードの切替オーバヘッド有り

○指針のみ選択すれば自動チューニング

△GCログが見にくい

動的GC 静的GC

○動作モードの切替オーバヘッド無し

△モード選択とチューニングが必要

○GCログが見やすい

○オブジェクトの移動コストが低い

△短寿命オブジェクトが多い場合は不適

シングルスペースGC 世代別GC

△オブジェクトの移動のコストがやや高い

○短寿命オブジェクトが多い場合に最適

○GCによる停止時間が理論上最小

△スループットは若干低下する

コンカレントGC パラレルGC

△GCによるアプリの一時停止が発生する

○アプリのスループットは理論上最高

Out of Memory

スローダウン

コアダンプ

JVMクラッシュ

サーバログ

スレッドダンプスタックスレッド

落ちた瞬間の情報のみ

ログに有益な情報が出ているとは限らない

障害直前のダンプは大抵取れてないマシンクラッシュ

OSクラッシュ

現象システム的原因調査手段問題点

アプリ不具合

ソースコード

メモリの利用状況と

GC発生状況が分かるのみ

運用担当者が見ても分からない

確固たる情報が得られず、デバッグログを仕掛けたり、

推測によるアプリ修正をして再現待ち

・・・迷宮入

GCログり

GC頻発

障害パターンと調査方法（一般）

Out of Memory

スローダウン

コアダンプ

JVMクラッシュ

サーバログ

スレッドダンプスタックスレッド

マシンクラッシュ

OSクラッシュ

現象システム的原因調査手段

アプリ不具合

ソースコード

調査に必要な情報が Flight

Recorderで既に取得できているため、速やかに問題を特定し修正

GCログ GC頻発

JRo c ki t F lig ht Re c o rd e r

+

循環バッファ

障害パターンと調査手段（JFR利用時）

JRockit Flight Recorder + Mission Control Client JVMの挙動の常時記録と分析

 独自の低負荷技術により本番環境での常時記録を実現



記録時のオーバヘッドは一般的に 2% 以下

 記録した情報を自動ファイル出力

 迅速な原因究明を支援する GUI ツール

ヒープメモリ利用率の増加傾向ヒープメモリを占めるオブジェクトの割合と増加率

1. トラブルの確実な原因追究を「遡って」実施可能

2. 障害発生→改善のサイクルと手間を大きく短縮化

JRockit Flight Recorderの特長

 JRockit R28 からの新機能

 JVM の常時診断

 JVM内の”循環バッファ”に診断データを保持

 新しいデータが入ってくると、古いデータは破棄される

 JVM だけでなく、 WebLogic Server 、および

WebLogic Server 上のアプリからのイベントも常時収集

 低オーバヘッド（ 0.5 ～ 2% ）

 JRockitの既存のカウンタを利用

 JRockit Mission Control で分析

 従来の JRMC Runtime Analyzer と Latency Analyzer 機能では不可能だった過去に遡っての分析が可能に！

Flight Reco rding

New Data

Old Data

Time

JRockit JVM

Flight Recorder Runtime

循環バッファー Applicati

JRockit Mission Control WLDF

イベントイベント Applicati

on アプリ

Thread Buffer

Global Buffer

Disk File 新しいデータ

古いデータ

WLST

ドキュメント内スライド 1 (ページ 113-125)

2

以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。

アジェンダ

 JRockit Flight Recorderクイックレビュー

 目的や仕組み

 開始、終了方法

 イベント、テンプレート

 製品ライセンス（重要！）

 JRockit Flight Recorderのユースケース（デモ）

 課題1： ホットスポットを探す

 課題2： レイテンシー調査

 課題3： GCの調査

3

目標

 JRockit Flight Recorderの目的、使用方法を理解し、デモを 通じて適用イメージを体感する。

 ステップ1 （クイックレビュー）

 JRokit JVM, JRockit Flight Recorder, イベント、テンプレート、Mission Controlの概要を理解する。

 ステップ2

 JRockit Flight Recorderのデモから活用イメージを体感

4

5

JRockit Flight Recorder クイックレビュー

 目的や仕組み、記録の開始、終了方法

 イベント、テンプレート

 製品ライセンス（重要！）

JRockit JDKとは？

 概要

 Oracleが提供＆サポートするJava SE完全準拠のJava開発・実行環境

 サーバサイド用途専用に設計された高信頼性の JVM

※現在はクライアントサイド用途にも対応

 Intel アーキテクチャ（ Xeon, Itanium2 ）へ最適化された業界最高速の JVM

※現在はSparc版も提供

 歴史

 1998 年 スウェーデン アピールバーチャルマシン より初版がリリース

 2002 年 BEA が アピールバーチャルマシン を買収

 2008 年 Oracle が BEA を買収

 Java SE との互換性

 java –version でベースとなる Java SE のバージョンを表示

JRockitのコード生成戦略

 プラットフォーム非依存性を損なわずに高速性を実現

 バイトコードを1ステップずつ毎回解釈しながら実行するインタプリタ方 式は低速なのでもとより不採用

 全バイトコードを事前にネーティブコード化するAOT（Ahead-of-time Compilation）方式はプラットフォーム間の移植性を損なうので不採用

 サーバサイドで実行されるアプリケーションの特徴を考慮

 大部分のロジックは静的であり、実行時に変更されることは稀である

 同一のロジックが長時間に渡って繰り返し実行される

 ネーティブコード生成・最適化のコストは、実行時に十分ペイ できると判断し、JRockitでは以下の方針を採用

 初回実行時にネーティブコードを生成

 実行時統計からのフィードバックをもとにネーティブコードをさらに最適 化

7

JRockitのGCモードの選択におけるトレードオフ

8

動的GC 静的GC

シングルスペースGC 世代別GC

コンカレントGC パラレルGC

Out of Memory

JVMクラッシュ

OSクラッシュ

現象 システム的原因 調査手段 問題点

GC発生状況が分かるのみ

確固たる情 報が得られ ず、デバッ グログを仕 掛けたり、

推測による アプリ修正 をして再現 待ち

・・・迷宮入

GCログ り

GC頻発

障害パターンと調査方法（一般）

Out of Memory

JVMクラッシュ

OSクラッシュ

現象 システム的原因 調査手段

調査に必要 な情報が Flight

Recorderで 既に取得で きているた め、速やか に問題を特 定し修正

GCログ GC頻発

JRo c ki t F lig ht Re c o rd e r

+

循環バッファ

障害パターンと調査手段（JFR利用時）

JRockit Flight Recorder + Mission Control Client JVMの挙動の常時記録と分析

 独自の低負荷技術により本番環境での常時記録を実現



 課題1：ホットスポットを探す

 課題2：レイテンシー調査

 JRockit Flight Recorderの目的、使用方法を理解し、デモを通じて適用イメージを体感する。

 1998 年スウェーデンアピールバーチャルマシンより初版がリリース

 2002 年 BEA がアピールバーチャルマシンを買収

 バイトコードを1ステップずつ毎回解釈しながら実行するインタプリタ方式は低速なのでもとより不採用

 ネーティブコード生成・最適化のコストは、実行時に十分ペイできると判断し、JRockitでは以下の方針を採用

 実行時統計からのフィードバックをもとにネーティブコードをさらに最適化

現象システム的原因調査手段問題点

確固たる情報が得られず、デバッグログを仕掛けたり、

推測によるアプリ修正をして再現待ち

GCログり

現象システム的原因調査手段

調査に必要な情報が Flight

Recorderで既に取得できているため、速やかに問題を特定し修正

1. トラブルの確実な原因追究を「遡って」実施可能

 新しいデータが入ってくると、古いデータは破棄される

WebLogic Server 上のアプリからのイベントも常時収集

 従来の JRMC Runtime Analyzer と Latency Analyzer 機能では不可能だった過去に遡っての分析が可能に！