JRockit Flight Recorder ハンズオンŸ¿を及ぼしているような状況です。 Flight Recorder を利用することでこの手の問題を調査しやすくなります。

1 / 28

Copyright(c) 2011, Oracle. All rights reserved.

JRockit Flight Recorder ハンズオン

日本オラクル株式会社

Fusion Middleware 事業統括本部ソリューション本部

Application Grid ソリューション部

シニアセールスコンサルタント関屋信彦

2011年 11月 10日

2 / 28


3 / 28


このドキュメントには「Oracle JRockit Flight Recorder」ハンズオンセッション

で行う一連の演習手順について記載してあります。ハンズオンセッション時間は

限られていますので、「特別演習」を飛ばして演習を行っていただいて構いませ

ん。「特別演習」は後から実施しても問題ないように構成されています。

Introduction ........................................................................................................... 4

Starting JRockit Mission Control ........................................................................... 4

演習 1.a – Starting the Stand Alone Version of JRMC ...................................... 5

演習 1.b – Starting JRMC in Eclipse .................................................................. 6

JRockit Flight Recorder ......................................................................................... 7

演習 2.a – Starting a JFR Recording ................................................................. 7

演習 2.b – Hot Methods ..................................................................................... 9

演習 3 – Latencies ........................................................................................... 10

特別演習 4 – Garbage Collection の振る舞い ................................................. 13

特別演習 5 – WebLogic Server Integration ...................................................... 13

特別演習 6 – Exceptions ................................................................................. 15

JRockit Memory Leak Detector ........................................................................... 17

演習 7 – Finding a Memory Leak ..................................................................... 17

特別演習 8 – On Line Leak Hunting ............................................................... 19

Management Console (特別演習) ....................................................................... 21

演習 9.a – The Overview ................................................................................. 21

演習 7.b – The MBean Browser....................................................................... 22

演習 7.c – The Threads View .......................................................................... 23

特別演習 7.d – Triggers .................................................................................. 25

JRCMD (JRockit CoMmanD) (特別演習) ............................................................ 25

4 / 28


Introduction Oracle JRockit Mission Control は Java アプリケーションのモニタリング、プロ

ファイリング、メモリーリークの追跡、原因特定に適したツールです。現在この

ツールは JRockit JVM に特化していますが、将来的にはこの JRockit の技術は

HotSpot JVM にもマージされる予定ですので JRockit Mission Control が HotSpot

JVM でも利用されるようになるでしょう。

現バージョンの Mission Control は次の三つのツールから構成されています。

Management Console – JVM とアプリケーションのモニタリングソリュ

ーションで JMX をベース技術としています。

Flight Recorder – オーバーヘッドの小さいプロファイリングツール

Memory Leak Detector – オンラインでメモリーリークを検知でき、Java

のヒープ内を分析できるツール

このチュートリアルは JRockit Flight Recorder を中心に構成されています。

JRockit Memory Leak Detector と JRockit Management Console につきましては

特別演習としています。JRockit Mission Control はスタンドアロン形式での利用

ができますし、Eclipse の内部で実行して利用することもできます。このチュー

トリアルでは基本的に後者の利用を前提としています。

このドキュメント内に記述しているコマンドは全て「/home/oracle/4.0_labs」デ

ィレクトリ配下にあります。以下のように 4.0_labs ディレクトリ配下に移動し

た上でコマンドを実行してください。

cd 4.0_labs ./startJRMC.sh

GUI 操作につきましては次のような表記法を用いています。これは Eclipse 等で

メニュー操作をするにあたり、選択するメニューを | で区切って順番にサブメニ

ューを選択していく事を意味しています。メニューの一部は（）で日本語訳を記

述しています。

File | Open File…

File | Open File…（ファイルを開く）

Starting JRockit Mission Control この演習では二通りの JRockit Mission Control 実行方法を利用しています。一つ

は JRockit Mission Control をスタンドアロンアプリケーションとして実行する方

法、もう一つは Eclipse 内での内部実行です。

この演習ではスタンドアロンと Eclipse プラグインの両方の JRockit Mission

Control の起動方法について学習します。

5 / 28


演習 1.a – Starting the Stand Alone Version of JRMC

/home/oracle/4.0_labs フォルダに移動して startJRMC.sh を実行します。

JRockit Mission Control の初期画面が表示されます。画面左上部分が「JVM ブ

ラウザ」でここにはローカルで実行されている JVM や JRockit Discovery

Protocol (JDP)をオンにして実行しているネットワーク上の JVM が自動検出され

て表示されます。「コネクタ」配下にはユーザ定義済みの JVM 接続が表示され

ます。

JRockit のツールを起動するには、 JVM ブラウザ上で JVM を選択して利用した

いツールをコンテキストメニューから選択するか、 JVM ブラウザウィンドウ内

6 / 28


のツールバー上で起動します。例えば JRockit Mission Control Management

Console は JVM ブラウザ上で JVM を右クリックしてメニューから「コンソー

ルの起動」を選択します。 Management Console は上図のように JVM ブラウザ

上で Management Console アイコンをクリックすることでも起動できます。

ここでは JVM ブラウザ内では Mission Control を動かしている JVM が This

Mission Control として表示されています。

このチュートリアルでは以降、JRockit Mission Control は Eclipse から起動しま

す。今起動しているスタンドアロンの JRockit Mission Control は終了してくだ

さい。終了するには JRockit Mission Control のウィンドウを閉じるか、ファイル

| Exit を選択します。

演習 1.b – Starting JRMC in Eclipse

はじめに startEclipse.sh を実行して Eclipse を起動します。このプログラムはあ

らかじめ workspace と JVM が設定済みの Eclipse を起動します。起動後は次の

図のように Java perspective が選択されています。（他の perspective が選択さ

れている場合は次の図のように Java perspective を選択してください。）

画面左部にはそれぞれの演習用に用意されたプロジェクトが表示されています。

パースペクティブを選択するボタンは画面の右上にあります。例えば「Mission

Control perspective」を選択することで Eclipse 内の画面を JRockit Mission

Control モードに切り替えることができます。

7 / 28


ここでは次のように Eclipse (JRockit Mission Control)を実行している JVM が

This Eclipse という名前で表示されています。

JRockit Flight Recorder JRockit Flight Recorder(JFR)は JRockit Mission Control のツールの中でメインと

なる JVM プロファイラです。レコーダー部分は JRockit の中で実装されていて、

JRockit 自身の情報と JRockit 上のアプリケーションの情報を収集します。レコ

ーダーは飛行機のブラックボックス化されたフライトデータレコーダーのよう

に情報を継続収集することも、期間限定で情報収集することも可能です。

演習 2.a – Starting a JFR Recording

フライト記録の開始方法にはいくつかの方法があります。この演習ではフライト

記録ウィザードを利用します。まず、「HotMethods」プログラムを開始します。

ここでは Java perspective に切り替えて、実行 | ヒストリーの実行 | HotMethods

を選択します。

「HotMethods」プログラムを実行した後に Mission Control perspective に切り

替えます。 JVM ブラウザ上に HotMethods クラスを実行している JVM が新たに

検知されて表示されます。

8 / 28


この HotMethods を右クリックして「フライト記録の開始」を選択します。フラ

イト記録の開始ウィザードで「例外を含むプロファイリング（組込み）」を選択

し、一定時間の記録フィールドに「2 min」を入力します。ファイル名はプロジ

ェクトの場所で適切な名前を選択します。ここではデフォルトのまま OK をク

リックしてレコーディングを開始します。レコーディングが終了するまで２分待

ちます。

レコーディングの進捗は次の図のように「フライト・レコーダー・コントロー

ル」の「残り時間」と「記録（x%）」部分で確認することができます。

9 / 28


2 分後、下記のようなレコーディング概要が表示されます。

演習 2.b – Hot Methods

実行に最も時間を要する部分（ホットスポット）がアプリケーションのどこにあ

るかを発見するのはアプリケーションのプロファイリングの一部です。このホッ

トスポットは大抵、アプリケーションの最適化を行う上で非常に重要な場所とな

ります。なぜならこの部分のオーバーヘッドを取り除くことでアプリケーション

の実行パフォーマンスに大きく影響するからです。

それではレコーディングの結果画面でコード | Hot Methods(ホット・メソッド)

に移動します。（注：演習 2.a の手順をスキップされた方は、レコーディング結

果はありませんが、あらかじめ同プロジェクト内に用意してあるレコーディング

結果ファイルを利用することができます。このファイルを参照するには Java

perspective を選択し、2_JFR_HotMehods プロジェクト中の hotmethods.jfr を

ダブルクリックしてから Mission Control perspective に切り替えます。）

画面中央部の「ホット・メソッド」でリストされているメソッドの一つが突出し

てサンプル・カウントが大きくなっています。これは他のメソッドと比較して

より多くの時間を実行に費やしている事を意味します。

1. どのメソッドが最もホットなメソッドですか？

2. そのメソッドはどこから呼び出されていますか？

10 / 28


3. このアプリケーションのパフォーマンスを改善するための最適化をどのメソ

ッドで行うのがよいでしょうか？

ヒント：ホットスポットそのものは大抵アプリケーションでは直接制御できません。アプリケーション的に制御できる個所を辿りましょう。

ホット・メソッドの追跡演習が完了したら、実行中の HotMethods アプリケーシ

ョンは停止します。停止するには Java perspective | コンソール | Terminate（赤

い■）をクリックしてください。

特別演習：

1. ソースコードを一行変えて、プログラムの実行効率を上げてください。

(10 倍以上の効率化が可能です。)

ヒント：もしお手上げならプロジェクトの Readme.txt が参考になります。

Tips：リソースの無駄使いとならないよう、不必要になったレコーディングファイルは Eclipse 上で必ず閉じるようにしてください。

この演習で得られた教訓は「アルゴリズムやデータ構造を誤って利用することで、どんなに JRockit JVM が早くともパフォーマンス問題が発生する」です。

演習 3 – Latencies

プロファイリングのもう一つのアプローチとしてレイテンシー調査が挙げられま

す。CPU 使用率は高くないにもかかわらず期待したスループットが出ない場合、

これは実行スレッドの失速に原因していることがあり、このようなケースでレイ

テンシー調査を行います。例えばスレッドの同期処理がアプリケーションに悪影

響を及ぼしているような状況です。 Flight Recorder を利用することでこの手の

問題を調査しやすくなります。

今回のハンズオンキットにはよくあるテレビの料理番組のように、すでに記録済

みのレコーディングファイルが提供されています。ここではレコーディング時間

の時短のため、 Eclipse で Java perspective に切り替えて

3_JFR_Latencies/latency.jfr をダブルクリックしてファイルを開いてください。

それから Mission Control perspective に変更してイベント | Graph（グラフ）を

選択します。

11 / 28


この図のように「イベント・タイプ」ビューをクリックしてこれを画面左上部

で表示します。イベント・グラフの main が折りたたまれている場合は main の

前の+をクリックして展開します。

1. どのタイプのイベントが多くを占めているでしょうか？

2. どのクラスがスレッドをブロックしているロックでしょうか？

3. どこでこのイベントが発生しているでしょうか？

ヒント：イベント | Trace（トレース）を選択して、ブロッキングイベントのみ

を表示させます。ここでは画面左部「イベント・タイプ」ビューの「Java

Blocked」だけにチェックを入れます。次に CPU/スレッド数 | Contention（競

合）を選択します。

イベント | Trace（トレース）を選択して、「Trace Tree（トレース・ツリ

ー）」テーブルの「期間」カラムをクリックしてソートして最もレーテンシーの

大きいものを上位に表示させます。最もレーテンシーの大きいものを詳細にドリ

ルダウンしていきます。

注: : 今回のケースではトレースの深さがとても浅いですが、より複雑なシナリオでは深くなります。

Java のスレッドをブロックしているイベントのほとんどが同じソースが原因と

なっています。

12 / 28


以上、収集した情報から、ワーカースレッドのほとんどがそれぞれ Logger クラ

スのロックで待ち状態になっていて、この Logger をコールしているのは全て

WorkerThread.run()メソッドということが判ります。

この問題を Fix するにはどのような方法がよいでしょうか？

ヒント： Logger.log(String) メソッドを右クリックして「メソッドを開く」を選択します。ここでは該当するメソッドは複数ありますのでこのうちの

3_JFR_Latencies のメソッドを選択します。実際に log メソッドのソースコードを見ると「 synchronized」となっていることがわかります。

今回の問題では複数の解決方法があります。

もし Logger が共有リソースを使用しなければ、Logger への相互呼び出しを削除

することができます。我々は単純に「 synchronization」をメソッドから削除す

ることができますし、またスレッドの全てで Logger を共有するのではなく、

個々のスレッドで Logger をそれぞれ利用するように修正することもできます。

これにより同期処理を減らすことができます。.

レコーディングファイル less_latency.jfr は単純に Logger.log(String)メソッドか

ら「synchronized」キーワードを削除して実行してからレコーディングしたもの

です。 latency.jfr と比較してみてください。何か違いがあるでしょうか？スレッ

ドが効率良くアプリケーションを実行しているでしょうか？

ヒント：Eclipse の画面で二つの jfr ファイルをドラッギング・ドッキング表示して比較することができます。

ヒント：イベント | Graph（グラフ）を見ると less_latency.jfr のほうは緑色のイベントが多くを占めており、スレッドが適切にアプリケーションを実行している事がわかります。一方で latency.jfr のほうはある時間帯で緑色になっているスレッドが一つしかなく、同時間帯でその他のスレッドが待ちになっていることがわかります。

ヒント：CPU/スレッド数 | Overview（概要）を選択して CPU 使用率を比較します。

この演習から得られた教訓は「同期処理の悪い設計がアプリケーションの性能を悪化させる」です。

演習 3 が完了したら、latency.jfr と less_lettency.jfr の画面を閉じます。

13 / 28


特別演習 4 – Garbage Collection の振る舞い

この演習ではレコーディング中に発生した Garbage Collection の詳細情報を取

得します。

4_JFR_GC プロジェクトで allocator.jfr ファイルを開き、Mission Control

perspective に切り替えます。Eclipse のエディタ部分で「allocator.jfr」を右クリ

ックして「最大化」を選択して画面を最大表示にします。（「allocator.jfr」をダ

ブルクリックしても画面の最大表示の切り替えができます。）

この状態でメモリー | GC Graph（GC グラフ）を選択します。このタブとその

隣の GC 詳細設定タブでレコーディング中の JRockit の全ての GC 情報を見るこ

とができます。GC グラフタブからは頻繁に GC が発生していたことが確認でき

ます。

メモリー | GC GENERAL（GC 全般）を選択し、 GC REQUEST TRACE TREE

（GC 要求トレース・ツリー）を見ます。何が GC の発生原因でしょうか？

メモリー | Allocation（割当て）を選択します。どのクラスのオブジェクトが最

もメモリーに影響を与えているでしょうか？「Allocation Pressure（割当プレッ

シャー）」の一番大きいものを選択してから「トレース」でドリルダウンしてメ

モリーアロケートの原因を確認します。

ヒント：ドリルダウンしたものを右クリックして「メソッドを開く」を選択し、ソースコードにジャンプして原因が何かを調査します。

特別演習:

1. 内部クラス「MyAlloc」を少し変更するだけで、処理内容自体は変更せず

にほとんど全てのオブジェクトアロケーションを止めて GC の発生を極小

化することができます。どのように修正すればよいでしょうか？

ヒント：今回の原因は Autoboxing に起因しています。

この演習で得られた教訓は「JVM のランタイム側での思いがけない所で発生する GC が大きくアプリケーションのパフォーマンスに影響する」です。

特別演習 5 – WebLogic Server Integration

JRockit Mission Control には機能拡張のためのプラグインがあります。この演習

では拡張プラグインによって提供される「WebLogic」タブグループを利用しま

す。これは WebLogic Diagnostics Framework(WLDF)と Dynamic Monitoring

System(DMS)によって提供されるイベントを分析するためのツールです。

5_JFR_WLS プロジェクトで medrec.jfr をダブルクリックして開きます。

14 / 28


このレコーディングファイルにはあまり沢山のデータが含まれていませんし、ア

プリケーションのウォームアップ前に記録されたデータが含まれています。しか

し、この演習では「WebLogic」タブグループでどのようなデータを見ることが

できるかについて焦点を当てていますのでこれで十分です。

1. どのサーブレットが平均実行時間がもっとも長くなっているでしょうか？

ヒント：WebLogic | Servlets を確認します。

/patient/login.do サーブレットの二つのイベントがありますが、もう少しこのイ

ベントに関して詳しく見ていきます。WebLogic | Servlets で/patient/login.do を

右クリックして Operative Set（操作セット） | Add Selection（選択項目の追

加）を選択します。画面上部のレンジセレクタで選択されたイベントが表示さ

れたのを確認します。（※「Operative Set」として色分けされています。）

次にイベント | Log（ログ）を選択します。画面左部でイベント・タイプビュー

を表示させて WebLogic Server イベントにチェックを入れます。

Show Only Operative Set（操作セットのみを表示）にチェックを入れて先ほど

選択したイベントのみを表示させます。

2. 二つの呼び出しで何か違いがあるでしょうか？

3. 二回目の呼び出し時に何が起きていたでしょうか？

ヒント：二回目のサーブレット呼び出しを右クリックして Operative Set

15 / 28


（操作セット） | Add matching ECID（一致項目の追加 ECID）を選択し

て表示されている ID を選択します。この操作により、同じトランザクシ

ョンのイベントが追加されます。

4. 同一トランザクション中で最後に実行された SQL は何でしょう？

5. どの EJB メソッドがこの SQL 実行のトリガーとなっていたでしょうか？

6. 実行にどれくらい時間がかかったでしょうか？

ヒント：イベント | Log（ログ） | Event Log（イベント・ログ）に一覧

表示されている項目のうち最後の JDBC Statement Execute を選択します。

発行された SQL とこのイベントの詳細は Event Attributes（イベント属

性）の Event Thread を展開することで確認できます。

イベント | Graph（グラフ）を選択してから Show Only Operative Set（操作セ

ットのみを表示）にチェックを入れます。マウスを使ってのズームアウト（拡大

表示する部分をマウスで範囲選択）と画面右下部にあるズーム調節機能を使って

イベントをズームアップさせます。これにより次の図のように関連するイベント

の相互作用が確認することができます。

特別演習 6 – Exceptions

過度の例外をスローするアプリケーションで、ほとんどの例外は catch されてロ

ギングされるようなアプリケーションがあるとします。これらの例外をハンドリ

16 / 28


ングするのは JVM にとってかなりコストの高い処理でパフォーマンスの低下を

招くことがあります。幸い本番環境でも JFR を利用することで、ある特定期間

で例外がどこでスローされたかを簡単に探し出すことができます。

6_JFR_Exceptions プロジェクトで exceptions.jfr を開きコード | Exceptions（例

外）を選択します。

いくつの例外がスローされているでしょうか？その例外はソースコードのどこで

発生しているでしょうか？

ヒント：カウント数の多い例外クラスを選択し、「トレース」を確認してどこで例外がスローされたかを調べます。

例外のいくつかは ScaryException インスタンスとなっています。この例外が時

間軸でみてどこでスローされているでしょうか？そしてそれはソースコードのど

こで発生しているでしょうか？

ヒント：例外クラス ScaryException を右クリックして Operative Set（操作セ

ット） | 選択項目の追加を選択します。この操作によって ScaryException がFlight Recorder 画面上部にある範囲選択の中で強調されます。次にイベント |

ログタブを選択し、「Show Only Operative Set（操作セットのみを表示）」のチェックボックスをチェックすることで次の図のように詳細情報を確認することができます。

17 / 28


JRockit Memory Leak Detector JRockit Memory Leak Detector を利用することでメモリーリークを発見したり、

オンラインでヒープの中身を分析することができます。

演習 7 – Finding a Memory Leak

Eclipse で Java perspective を選択してから実行 | ヒストリーの実行で Leak を

実行します。実行後に Mission Control perspective に変更し、JVM ブラウザで

Leak を右クリックして Start Memleak（Memleak の開始）を選択します。しば

らくするとメモリーリークの候補となる情報を収集します。

ここでは最もメモリリークしているタイプのオブジェクト参照を誰が保持してい

るかに興味があります。

「Growth Rate（増加率）」の最も高いものを右クリックして Add to Type

Graph（タイプ・グラフに追加）を選択すると自動的に「Type Graph（タイ

プ・グラフ）」タブに移動します。タイプノードが赤ければ赤いほど、増加率が

高い事を意味します。これはもっともメモリリークに関して疑わしい事を意味し

ます。このタイプでプラスのアイコンをクリックして展開していきます。

HashTable を乱用しているものがあるのが確認できますがこの原因は何でしょ

うか？

Java.util.Hashtable$Entry と Leak$DemoObject を結ぶ矢印を右クリックして

「List referring instances（参照中のインスタンスをリスト）」を選択します。

インスタンスはたくさんありますが、ここでは一つのインスタンスを選択して右

クリックして「Add to Instance Graph（インスタンス・グラフに追加）」を選

択します。Memleak は自動的にオブジェクト参照をルートまでトレースするこ

とができます。インスタンス・グラフで「java.util.Hashtable$Entry」を右クリ

ックして「Expand to Root（ルートまで展開）」を選択します。HashTable のフ

ィールド名が見つかるまで参照を辿ると Leak クラスの内部クラス

「DemoThread」でフィールド名「table」で保持していることが確認できます。

次の図がその表示例です。

18 / 28


また、あるタイプのオブジェクトがどこでアロケートされているかも見つけるこ

とができます。Trend（傾向）タブに戻り Leak$DemoObject クラスを右クリッ

クして Trace Allocations（割当のトレース）を選択します。

remove メソッドと比較して put メソッドでわずかに多くオブジェクトアロケー

トされていることが確認できます。put メソッドを右クリックしてメソッドを開

くを選択します。

特別演習：

1. メモリーリークの原因は何でしょうか？

2. 問題を fix して、リークが取り除かれた事を確認してください。

19 / 28


演習 7 が完了したら、Java perspective | コンソール | Terminate（赤い■）をク

リックして Leak アプリケーションを終了してください。

特別演習 8 – On Line Leak Hunting

この演習ではアプリケーションを実行して操作している間にメモリーリークを調

査します。この演習では次の図のように JRockit Memory Leak Detector を設定

します。この設定を行うことでインスタンス数の少ないクラスのインスタンス数

の変化もトレースできるようになります。この設定を行うには Eclipse のメニュ

ーでウィンドウ| 設定を選択し、フィルタ入力フィールド（type filter text）で

「Trend（傾向）」と入力して「Lowest heap usage to report（報告する最低の

ヒープ使用率）」に 0 を設定します。

注意：このハンズオンキットではすでに値が設定されています。

Eclipse の「ヒストリーの実行」から AddressBook アプリケーションを実行しま

す。「MemoryLeaker」というタイトルの画面が表示されますがそのままにして

おきます。次に Mission Control perspective に切り替え、JVM ブラウザで

AddressBook を右クリックして「Start Memleak（Memleak の開始）」を選択し

て JRockit Memory Leak detector を実行します。「Trend（傾向）」の「Filter

Column（列のフィルタ処理）」で「Address」を入力します。すると Address

クラスとその内部クラスが一覧に表示されます。

20 / 28


「Trend（傾向）」グラフをバックグラウンドで開いたまま AddressBook アプ

リケーションを操作します。複数のアドレスを add したり remove したときに何

が起こりましたか？何か不適切な点はありましたか？問題となる参照をどのクラ

スが保持しているかを探してみましょう？

ヒント：単純に不正な参照を残すには次の図のように全てのアドレスをまずクリアするのが最も簡単です。（詳細はプロジェクト内の Readme.txt を参照）

特別演習：

1. アプリケーションの不適切な部分を修正してください。

2. JRockit Memory Leak Detector で問題が修正された事を確認してくださ

い。

演習が完了したら AddressBook アプリケーションを終了してください。

21 / 28


Management Console (特別演習)

JRockit Management Console は JMX ベースのツールで JVM やアプリケーショ

ンをモニタリングすることができます。

演習 9.a – The Overview

今回はスタンドアロン版の JRockit Mission Control （startJRMC.sh）を起動し

ます。その後に LoadAndDeadlock を実行します。実行するにはコマンドライン

で loadAndDeadlock.sh を実行してください。

しばらくして LoadAndDeadlock が JVM ブラウザに表示されてから右クリック

で「コンソールの起動」を選択します。

Management Console が次の図のように表示されます。

概要タブではグラフの追加・削除ができます。また新しい属性をグラフに追加し

たり、グラフの情報をディスクにログ出力することも可能です。動的に更新され

るグラフをフリーズさせたり、ズームしてグラフを見たり、その他多くの操作が

できるようになっています。

ここではプロセッサグラフにスレッドカウントを追加してみましょう。

プロセッサグラフで追加… ボタンをクリックします。「属性セレクタ」ダイア

ログで「フィルタ」フィールドに「Th」と入力します。フィルタリングされた

22 / 28


もののうち「ThreadCount」を選択します。色はそれぞれ好みのものを選択して

ください。ThreadCount 値が 20 付近で推移するのが確認できます。

特別演習：

1. 約 20 であることはグラフ上でわかりますが正確な値はわかりません。グ

ラフで「更新の停止」ボタンをクリックしてグラフをフリーズさせた状態

でスレッドカウントグラフにマウスポインタを重ねます。

正確な ThreadCount 値は何でしょうか？

2. 概要タブのダッシュボードで画面右上に表示されている「Live Set」属性

の代わりに ThreadCount 値を表示させてみましょう。

演習 7.b – The MBean Browser

MBean ブラウザはプラットフォーム MBean サーバーの MBean 属性を見るため

に使用します。もしモニタリングするためのアプリケーション独自の MBean を

登録している場合はこの MBean ブラウザでも見ることができます。また更新時

間を変更したり、操作を実行したり、属性値をグラフに追加したりすることも可

能です。それでは MBean タブグループを選択して MBean ブラウザを使用しま

す。

現在の GC 戦略は何に設定されているでしょうか？

ヒント： oracle.jrockit.management を展開して GarbageCollector を選択し、

Strategy 属性を確認します。

今度は「java.lang」を展開して「Threading」を選択します。先ほどプロセッサ

グラフ表示を行った「ThreadCount」属性を確認することができます。今回はこ

の属性を MBean ブラウザからメモリグラフへ追加します。

属性を右クリックして「視覚化」を選択し、「メモリ」を選択します。もう一度

概要タブを表示して属性が追加された事を確認します。

23 / 28


特別演習：

1. スレッドダンプをとるために DiagnosticCommand で print_threads を実

行してください。

ヒント：MBean ブラウザで oracle.jrockit.management を展開して

DiagnosticCommand を選択します。操作タブで String を一つ引数にとる

操作 execute を選択して画面右部の呼出しボタンをクリックして

print_threads を入力してダンプを出力します。

2. より簡単な方法で診断コマンドを実行してください。

ヒント：詳細タブグループの「診断コマンド」タブで print_threads を実

行します。

演習 7.c – The Threads View

引き続きスタンドアロン JRMC 上でランタイム | スレッドを選択します。前の

演習ででてきた ThreadCount 属性は画面上部の「ライブ・スレッド・グラフ」

で確認することができます。次に「ライブ・スレッド」で「デッドロック検出」

チェックボックスにチェックを入れます。これで実行中のアプリケーションでデ

ッドロック検出を行うことができます。

24 / 28


次に「デッドロック」列をクリックしてデッドロックしているスレッドを上位に

表示します。

ヒント：「スタック・トレースのリフレッシュ」ボタンをクリックすることで画面の自動リフレッシュを止めることができます。この設定はアプリケーションを調査中の場合に有用な場合があります。この設定をしないと何かしらの原因でスタックスレッドの表示が更新されてしまうことがあります。

デッドロック中のスレッド名は何でしょう？どこのメソッドの何行目で発生して

いるでしょうか？

特別演習：

1. JRockit Mission Control を Eclipse 内で実行している場合は該当するソ

ースコードへジャンプできます。「選択したスレッドのスタック・ト

レース」フレーム内で該当するメソッドを右クリックしてソースコー

ドへジャンプし、ソースコードを修正して問題を解決してください。

25 / 28


特別演習 7.d – Triggers

CPU 使用率が高すぎるのは何かしらのトラブルを意味することがあります。こ

ここでは CPU 使用率が 50%を超えた場合にアラートをあげるトリガーを設定し

ます。

引き続き JRMC から、MBeans | トリガーを選択します。追加… ボタンをクリ

ックして oracle.jrockit.management.Runtime/CPULoad 属性を選択します。

「Next」ボタンをクリックして最大トリガー値に 0.5 を入力して Next をクリッ

クします。トリガーアクションはデフォルトの「アプリケーション・アラート」

を選択して「Next」ボタンをクリックします。「制約の選択」画面で制約を設

定することができますが、ここではそのまま「Next」ボタンをクリックします。

ルール名を適当に入力して「Finish」ボタンをクリックします。デフォルトでは

トリガーは無効になっていますので設定したトリガー名のチェックボックスにチ

ェックを入れて有効化します。トリガーを有効化したのを確認するために全般 |

概要を選択してから何かしらのアクションを行い、アラートが上がるのを確認し

ます。確認ができたらトリガーを削除します。

JRCMD (JRockit Command) (特別演習)

この演習では JRockit のコマンドラインツール jrcmd を利用します。

このツールは通常 JROCKIT_HOME/bin 内にあります。このハンズオンキットで

はコマンドラインで「. ./setenv.sh」（最初のドットの後は半角スペース）を実

行すれば必要なパス設定がされているのですぐに jrcmd を実行することができま

す。

26 / 28


まずはじめに任意の Java アプリケーションを実行します。もし Eclipse かスタ

ンドアロンの JRockit Mission Control を実行しているのであればこのステップは

省略できます。

次にコマンドラインで jrcmd を入力します。これで今実行中の Java プロセスの

プロセス ID のリストが表示されます。JRCMD 自身が Java アプリケーションで

すので自分自身もリストされているのが確認できます。

jrcmd は PID を使って JVM と通信します。jrcmd <PID> help と入力してくださ

い。これで利用可能な診断コマンドがリストされます。もし <PID>に 0 を指定

した場合には全ての JRockit にコマンドが送信されます。

実行中の JRockit の全てのバージョンを一覧表示します。

特別演習：

1. Eclipse で「ヒストリーの実行」から Leak を実行します。

次に jrcmd <PID> print_object_summary コマンドを実行します。<PID>

は実際の Leak プログラムの PID を指定します。しばらくして

print_object_summary コマンドを再実行します。差分情報から何か手掛

かりが得られたでしょうか？

27 / 28


Tips：もし JRockit JVM が起動しているマシンとは別のマシンからリモートアクセスして JRockit Mission Control のツールを利用したい場合はあらかじめ

「java –Xmanagement:autodiscovery=true,authenticate=false,ssl=false

port=7901 MyAPP」のように監視対象 JVM 側で JVM 引数を設定しておく必要があります。

この手順と同等の設定を JVM 起動中に行うには

「jrcmd <PID> start_management_server authenticate=false ssl=false

port=7901」を実行します。

2. JFR のレコーディングを JRCMD から開始してください。

ヒント：start_flightrecording を利用します。

28 / 28


3. Eclipse の「ヒストリーの実行」から ExceptionThrower を起動します。

ウィンドウ｜パースペクティブを開くから Debug perspective に切り替え

てから ExceptionApplication アプリケーションを選択してコンソールビュ

ーをダブルクリックして最大化します。次にコマンドラインで jrcmd を実

行して ExceptionApplication の PID を確認します。jrcmd <PID> verbosity

set=exceptions=info を実行してから再度最大化した Eclipse のコンソール

を表示させます。何が起きているでしょうか？

4. 次に jrcmd <PID> verbosity set=exceptions=debug を実行します。何が起

きたでしょうか？最後に jrcmd <PID> verbosity set=exceptions=quiet を

実行します。

ヒント：JRockit のその他のモジュールについてもこの手順はログメッセージの冗長性設定に適用できます。上記手順は非常に有用です。

注: : 演習 7.b の DiagnosticCommands と JRCMD はとても似ています。実際にjrcmd で出来ることは全て DiagnosticCommand MBean で出来ます。その逆も同じです。

Documents

JRockit Flight Recorder ハンズオンŸ¿を及ぼしているような状況です。 Flight Recorder を利用することでこの手の 問題を調査しやすくなります。

JRockit Flight Recorder ハンズオンŸ¿を及ぼしているような状況です。 Flight Recorder を利用することでこの手の問題を調査しやすくなります。