この章では、この統合をWebLogic Serverに基づく本番システムに対しての包括的なパフォーマンス分析および診断ファウンデーションに提供する方法を表示する共通使用方法のシナリオについて説明します。
この章には次の項が含まれます:
Javaフライト・レコーダは、パフォーマンス監視およびプロファイリング・ツールで、診断情報を継続的に記録し、システム・クラッシュなどの壊滅的な障害が発生しても、常に診断情報を提供します。Javaフライト・レコーダは、Oracle HotSpotで使用できます。WebLogic ServerにHotSpotが構成されている場合、Javaフライト・レコーダはデフォルトでは有効化されていません。WebLogic ServerでJavaフライト・レコーダを有効化する方法の詳細は、「Oracle HotSpotと連携したJavaフライト・レコーダの使用」を参照してください。
注意:
このリリースのWebLogic Serverでサポートされている構成についての最新情報は、Oracle Technology NetworkのOracle Fusion Middlewareのサポートされるシステム構成を参照してください。
Javaフライト・レコーダは、必要に応じてアクセスできるフライト記録またはJFRファイルと呼ばれる診断およびプロファイリング・データのバッファを保持します。図4-1で示されているように、フライト記録機能は、新しいデータが継続的に追加され、古いデータが削除される航空機の「ブラック・ボックス」と同じ方法で動作します。
JFRファイルのデータには、JVMからのイベントおよびWebLogic ServerとOracle動的モニター・システム(DMS)などの他のイベント・プロデューサが含まれています。イベントに対して生成されたシステム実行フローの詳細を検討するには、Java Mission Controlを使用して、JFRファイルをいつでも分析できます。
Javaフライト・レコーダが有効化された場合、またWLDFを構成してWebLogic Serverの診断を生成し、Javaフライト・レコーダによりキャプチャされるようにする場合、追加される処理オーバーヘッドの量は最小限です。これは、特に最大値を追加する本番環境でフルタイム・ベースで使用できます。
Javaフライト・レコーダには、主に次のような利点があります。
継続的に実行するように設計されている - フライト記録でキャプチャしたJVMとWLDFの両方のイベントでフルタイム・ベースで実行するようにJavaフライト・レコーダを構成すると、システム・クラッシュなどのイベントが発生したとき診断データを常に使用できます。これにより、イベントまでの診断データが使用できるようになり、イベントを再作成せずに診断することができます。
包括的なデータ - Javaフライト・レコーダでは、ランタイム・アナライザおよび待機時間分析ツールなどのツールにより生成されたデータが組み合され、1つの場所に表示されます。
イベント・プロバイダとの統合 - HotSpotでは、Javaフライト・レコーダによって、WebLogic Server、Oracle Dynamic Monitoring System (DMS)、および他のOracleの製品など追加システム・コンポーネントを監視できるAPIのセットが含まれます。
Javaフライト・レコーダの詳細は、次の場所にある『Java Flight Recorderランタイム・ガイド』を参照してください。
WebLogic ServerにOracle HotSpotが構成されている場合、Javaフライト・レコーダはデフォルトでは無効です。Javaフライト・レコーダを有効化するには、JVMが実行されるWebLogic Serverインスタンスに、次のJVMオプションを指定する必要があります。
-XX:+UnlockCommercialFeatures -XX:+FlightRecorder
注意:
JVMオプションをHotspotに指定する順番は、非常に重要です。オプションは左から右に向かって処理され、オプションの値が重複する場合は上書きされます。そのため、次の点に注意してください。
HotSpotでは、FlightRecorder
オプションの前にUnlockCommercialFeatures
オプションが付加されていなければ、認識されません。
FlightRecorder
オプションのみを指定した場合、またはFlightRecorder
をUnlockCommercialFeatures
を指定する前に指定した場合は、HotSpot JVMは起動しません。
Javaフライト・レコーダとの統合を利用するために、WLDFで提供される主な機能には次のものが含まれます。
フライト記録でキャプチャされたWLDF診断データ
フライト記録でキャプチャされたWebLogic Serverイベントの診断データを生成するようにWLDFを構成できます。キャプチャされたイベントには、Webアプリケーション、EJB、JDBC、JTAとJMSリソース、リソース・アダプタおよびWebLogic Webサービスなどのコンポーネントが含まれます。
WLDF診断ボリュームの調節
フライト記録のWebLogic Serverイベント・データを生成する機能は、WLDF診断ボリューム構成によって制御されます。この制御では、Javaフライト・レコーダによってキャプチャされたWebLogic Serverイベント・データの量も決定し、生成された各WebLogic Serverのデータ量を調整できます。詳細は、「WLDF診断ボリュームの構成」を参照してください
注意:
デフォルトでは、WLDF診断ボリュームは低
に設定されています。
WLDF診断ボリューム設定は、明示的に構成された診断モジュールまたは組込み診断モジュールには影響しません。
負荷時の生成されたイベントの自動スロットル
該当WebLogic Serverインスタンスで処理される負荷を増加すると、WLDFはイベント発生とJFRファイルに記録するために選択された受信WebLogic Serverリクエストの数を自動的にスロットルし始めます。システム負荷の増加および下落に伴って、スロットルの程度は継続的に調整されます。
スロットルには、3つの重要な利点があります。
Javaフライト・レコーダ用のWLDFによって発生したキャプチャ・イベントのオーバーヘッドは、システムが特に負荷のかかっている状況の場合、最小化されます。
フライト記録のバッファに含まれる時間間隔が最大化され、よりよい履歴レコード・データが取得できます。
スロットルには、サンプリング受信WebLogic Serverリクエストの影響があり、負荷のかかっている状況下でシステム・アクティビティの正確な包括的ビューを提供しながら高いパフォーマンスを維持します。
注意:
スロットルは、WLDFで取得したフライト記録データのみに影響します。これは、JVMなど、他のイベント・プロデューサによって取得されたデータに影響しません。
JFRファイル用のWLDF診断イメージ・キャプチャ・サポート
Javaフライト・レコーダによってJFRファイルが生成されている場合、WLDF診断イメージのキャプチャには自動的にJFRファイルが含まれます。JFRファイルには、WebLogic Serverを含むすべてのアクティブなイベント・プロデューサによって生成されたデータが含まれます。監視および通知コンポーネントを使用して取得したイメージには、可能な場合JFRファイルが含まれます。
診断イメージのキャプチャのコンテンツをダウンロードするWLSTコマンド
WLSTには、「診断イメージ・キャプチャのダウンロード用のWLSTオンライン・コマンド」で説明した診断イメージのキャプチャのコンテンツをダウンロードするコマンドが含まれています一般的には、これらのコマンドは、診断イメージのキャプチャに含むすべてのエントリのリスト、コピーおよびダウンロードに役に立ちますが、可能な場合、JFRファイルの取得にも使用できます。一度診断イメージのキャプチャから取得すると、JFRファイルはJava Mission Controlで表示されます。
この項では、重要な診断に関する問題を解決するために役に立つJavaフライト・レコーダを使用した3つの一般的なビジネス・ケースが要約されています。
Javaフライト・レコーダを使用するこれらのシナリオの詳細は、次の場所にある『Java Flight Recorderランタイム・ガイド』を参照してください。
重大な障害が発生した場合、Javaフライト・レコーダ・バッファの内容は、航空機のブラック・ボックスと類似した方法で問題発生後の解析として使用できます。アプリケーションの終了によって生じるJVMクラッシュまたはメモリー不足エラー(OOME)はこのような失敗の例です。
これらの状況では、フライト・レコードには、障害の原因を判別するのに役に立つ次の情報が含まれます。
クラッシュ時のJavaフライト・レコーダの構成のメタデータを含むJVMコア・ダンプ。さらに、設定されているディスク・ストレージのパラメータにより、Javaフライト・レコーダのデータ・バッファには、一定量のデータが格納されます。
障害が発生する前のWLDFによってキャプチャされたWebLogic Serverイベント。
Javaフライト・レコーダはメモリーとディスクの組合せを使用して、そのバッファを格納します。最新のデータはメモリーに格納され、「古く」なるとディスクにフラッシュされます。このように、停電または同様の重大な事態が起こった場合でもディスク上のデータは使用可能です。使用できなくなるのは、最新のデータのみです(たとえば、ディスクにフラッシュされていないデータ)。テキスト・ダンプ・ファイルには、適用可能な場合、データ・バッファへのパスを含むクラッシュ時のJavaフライト・レコーダ構成のメタデータがあります。Javaフライト・レコーダの使用方法の詳細は、次の場所にある『Java Flight Recorderランタイム・ユーザー・ガイド』を参照してください。
プロファイリングでは、特定時点で始まるデータがキャプチャされます。これによって、その時点の後に発生したイベントを分析することができます。次の項で説明するリアルタイム診断レポートとは対照的に、プロファイリングには、これより前のデータではなく、特定のイベントが発生した後に発生した診断データの分析が含まれます。
Javaフライト・レコーダでのプロファイリングにより、ロック競合の詳細分析および待機時間の原因を実行する機能を最適化できます。
これは、特定のイベントがそのイベントに先立つシステム・アクティビティを理解するために発生したときの実行時に生成される診断データを調査する際に特に便利です。たとえば、重大なエラー・メッセージが生成される前に発生するシステム・アクティビティなどです。Javaフライト・レコーダとともにWLDFで利用できる診断機能を使用して、問題が発生する場合に大量のシステム全体の診断データを取得できます。そして、それぞれのイベントを他のシステム・アクティビティに迅速に関連付けるよう、Java Mission Controlの機能を利用して、JFRファイルに指定されたスナップショット時間内に実行データを処理します。それにより、問題の原因を切り離すことができます。
Javaフライト・レコーダと組み合せて特に役立つWLDF機能の1つは、イメージ・アクションです。イメージ・アクションによって、診断システム・モジュールで構成されているポリシーのトリガーに応答して、診断イメージ・キャプチャが生成されます。ポリシーは、1つ以上の特定の条件に対してサーバー環境をモニターし、それらの条件が発生すると、自動的にイメージ・アクションを実行できます。フライト・レコーダが有効化されると、診断イメージ・キャプチャに自動的にJFRファイルが含まれます。また、JFRファイルを診断イメージ・キャプチャから抽出でき、ただちにJava Mission Controlで調査するか、後で分析するために保存できます。Javaフライト・レコーダによってWLDFデータが取得される際に使用するイメージ・アクションは、特に断続的な問題のリアルタイム診断に適しています。
イメージ・アクションは、WLDFのポリシーおよびアクション・システムの一部です。イメージ・アクションを設定するには、1つ以上の個別ポリシーを作成します。ポリシーには、ポリシーが検出するイベントを指定するためのJava EL式が含まれます。たとえば、次のログ・ポリシー式は、重大度レベルがクリティカル
でIDが BEA-149618
のサーバー・ログ・メッセージを検出します。
log.severityString == 'Critical' && log.messageId == 'BEA-149618'
ポリシーは次のいずれかを監視できます。
ローカル・ランタイムMBeanサーバー内のランタイムMBeanインスタンス
ランタイムMBean属性が高メモリー使用率またはサーバーとのオープン・ソケット接続に関する問題などのパフォーマンス問題を検出する場合、スケジュール済ポリシーがイメージ通知を実行できます。
サーバー・ログに発行されたメッセージ
特定のメッセージ、重大度レベルまたは文字列を発行する場合、ログ・ポリシーがイメージ通知を実行できます。
WLDFインストゥルメンテーション・コンポーネントで生成されたイベント
インストゥルメンテーション・サービスが特定のイベントを生成する場合、イベント・ポリシーがイメージ通知を実行できます。
詳細については、次のトピックを参照してください。
次の項では、診断イメージ・キャプチャからのJFRファイルの取得方法およびJFRファイルにあるWebLogic Serverイベントを確認するためのJava Mission Controlの使用例について説明します。
診断イメージ・キャプチャ自体は、異なるサーバー・サブシステムで作成された個々のイメージを含む単一のJFRファイルです。JFRファイルがある場合、それはファイルFlightRecording.jfr
として診断イメージに含まれています。
診断イメージ・キャプチャは、たとえばWebLogic Server管理コンソール、Fusion Middleware Control、WLSTまたはJMXアプリケーションなどのオンデマンドで生成できます。または、イメージ・アクションの結果として生成できます。診断イメージ・キャプチャの生成方法および作成される場所の構成方法の詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの診断イメージの構成と取得に関する項を参照してください。
JFRファイルの内容を表示するには、まず初めに、「診断イメージの構成と取得」の説明に従って、診断イメージ・キャプチャからJFRファイルを抽出する必要があります。JFRファイルを抽出した後、Java Mission Controlでその内容を表示できます。
たとえば、診断イメージ・ファイルからJFRファイルを取得して、ローカル・ディレクトリに保存するWLSTスクリプトは、「サンプル: 診断イメージ・キャプチャからのJFRファイルの取得」を参照してください
Java Mission Controlを使用して、診断イメージ・キャプチャから抽出した後にJavaフライト・レコーダ・ファイルの内容を確認できます。次の項では、WebLogic ServerイベントのWLDFのみならずHotSpotなどの他のすべての使用可能なイベント・プロデューサから生成された診断データにドリルダウンするために、ツール・サポートの大部分を指定するJava Mission Controlグラフィカル・ユーザー・インタフェースの機能の一部について説明します。
Java Mission Controlインタフェースの詳細は、次の場所にある『Java Mission Controlユーザーズ・ガイド』を参照してください。
http://docs.oracle.com/javacomponents/index.html
注意:
フライト・レコーダ・データには、キャプチャされたJFRイベントのpartition-id
やpartition-name
が含まれることがありますが、パーティション・ユーザーがアクセスできるのは、そのユーザーのパーティションに対応する情報を含むJFRデータのみです。詳細は、『Oracle WebLogic Server Multitenantの使用』の、パーティションの監視とデバッグに関する項を参照してください。
Java Mission ControlにはJavaフライト・レコーダ・グラフィカル・ユーザー・インタフェースが含まれており、これによりOracle HotSpotのJavaフライト・レコーダ対応バージョンを実行しているユーザーはJVMの記録、現在の記録設定およびランタイム・パラメータを表示できます。JFRインタフェースには、イベント・プロデューサおよびタイプ、イベント・ロギングおよびグラフ化、スレッドによるイベント、イベント・スタック・トレースおよびイベント・ヒストグラムなどのJFRファイルに記録されたイベント情報に直接アクセスできるイベント・タイプ・ビューが含まれています。
Javaフライト・レコーダ・インタフェース内の「概要」タブは、ボトルネックや、貧弱なシステム・パフォーマンスの他の原因を示す動作を明らかにできるので、システムの一般的なヘルス状態の分析に役立ちます。図4-2には、イベント・タイプ・ビュー内の「概要」タブの例を示します。
図4-2で示した情報について次の点に注意してください。
「イベント」タブ・グループのアイコンを選択して、「イベント・タイプ」ビューが表示されます。
Javaフライト・レコーダ・ファイル名が「概要」タブの上部に表示されます。Javaフライト・レコーダは常にFlightRecording.jfr
と名付けられており、診断イメージ・キャプチャからダウンロードした後、これをわかりやすい名前に変更すると便利です。
左側の「イベント・タイプ」ブラウザは、記録にある使用可能なイベントを表示するツリーです。これは「イベント」タブ・グループとともに機能し、関心のあるイベントまたはイベントのグループを選択し、それについて詳細な情報を取得できます。
「イベント・タイプ」ブラウザでエントリの選択または選択解除すると、「概要」タブで表示される情報が動的にフィルタされます。たとえば、WebLogic Serverのみ選択すると、すべての非WebLogicイベント・プロデューサがフィルタされ除去されます。
範囲ナビゲータは、「概要」タブ・タイトルの下に表示されるグラフであり、選択したタブで表示されるデータに関連する記録のすべてのイベントを表示するタイムラインです。表示されたデータの範囲を調整するためにボタン・セットがあります。これによって、Javaフライト・レコーダ・データの詳細へのドリルダウン処理が簡略化されます。
「プロデューサ」セクションでは、表示されているデータが発生した各イベント・プロデューサを識別されます。各プロデューサにメトリックがあり、表示されたイベント・データの総数セットの一部として各プロデューサによって生成されたアクティビティのボリュームを示します。
「イベント・タイプ」セクションでは、各イベント用の主要なメトリック・データとともに、「概要」タブに表示されるすべてのイベントがリストされます。
図4-2 Java Mission Control内のJavaフライト・レコーダ・ファイルの概要ページの例
この項では、WebLogic ServerでホストされるWebアプリケーション内の特定のリクエストに関連付けられたイベント・アクティビティを識別するために開発者およびサポート・エンジニアが使用する手順の例を示します。この例は、パフォーマンスの問題を診断する特定の方法をお薦めするものではありませんが、パフォーマンスの問題を検索して分析するプロセスを簡単にすることのできるJavaフライト・レコーダ・グラフィカル・ユーザー・インタフェースの使用方法を簡単に示します。
この項では、次の例を説明します。
Java Mission Controlを起動してJFRファイルを開く場合、分析する特定のイベントを迅速に選択するよう「イベント・タイプ」ビューを使用できます。「イベント・タイプ」ブラウザ(イベント・タイプ・ビューで使用可能)のアイテムを選択および選択解除することで、選択したイベント・タイプのみの情報を表示するようにJavaフライト・レコーダ・グラフィカル・ユーザー・インタフェースで表示される情報が迅速に変更されます。
図4-3は、サーブレット・イベント・タイプのみを選択している状態でのイベント・タイプ・ブラウザを示します。
1つ以上のイベント・タイプによって記録されるイベントの詳細を表示するには、Javaフライト・レコーダ・グラフィカル・ユーザー・インタフェースの下部にある「ログ」タブを選択します。サーブレット・イベント・タイプの「ログ」タブの例を、図4-4に示しています。
「ログ」タブを使用する場合は、次のようにイベントの詳細を表示できます。
「イベント・ログ」表の個々の列の先頭をクリックして、イベントのソート順を変更できます。たとえば、「期間」列をクリックすると、実行に最長時間がかかったイベントを迅速に識別できます。
「イベント・ログ」表でイベントを選択すると、「イベント属性」表ではそのイベントの詳細が表示されます。たとえば、図4-4では、次の属性を示します。
イベントの開始時間、終了時間および継続時間
サブーレットでリクエストを発行したユーザーのID
呼び出されたサーブレットのメソッド、クラス名およびURI
パーティションIDおよび名前 - サーバーまたはドメイン・スコープ・リソースのかわりに生成されたイベントは、0
のpartition-id
およびDOMAIN
のpartition-name
でタグ付けされます。
関係ID (RID)。1つのリクエストにおいて、特定のプロセス上の特定スレッドで実行された作業と、同じプロセスの別のスレッドおよび別プロセス上で実行された作業を区別します。詳細は、『Oracle Fusion Middlewareの管理』のログ・ファイルおよびコンポーネント全体でのメッセージの関係付けの理解に関する項を参照してください。
実行コンテキストのID (ECID)
異なるイベント・タイプには異なる属性があります。たとえば、JDBCイベントの場合、SQL文、使用したJDBC接続およびこれを呼び出したスタックを表示する属性をスクロールできます。インタフェースによって、詳細に分析できる予期しない動作を簡単にスキャンできます。
注意:
ECIDの値は一意の識別子で、各イベントを同一のリクエスト実行フローの一部として相関させるために使用できます。たとえば、操作セットの分析による実行フローのトラッキングに関する項で示されるように、特定のリクエストに関連すると識別されるイベントは、通常、同一のECID値を持ちますただし、ECID文字列自体の形式は、変更しやすい内部メカニズムによって決定されるため、その形式に依存関係を持ったり配置してはなりません。
Java Mission Control内のJavaフライト・レコーダ・グラフィカル・ユーザー・インタフェースでは、特定のイベントの結果として発生したシステム・アクティビティのランタイム・トレイルを分析できます。この例では、まず操作セットが定義され、ランタイム・トレイルが分析されます。操作セットは、Java Mission Controlで動作するために選択するイベントのいずれかのセットです。
この項に示された例では、操作セットが、図4-5で示した「イベント・ログ」表で選択したサーブレット呼出しイベントとして、同じ実行コンテキストID (ECID)属性を持つイベントのために作成されます。操作セットは、そのサーブレット呼出しの結果とした実行フローを参照するために分析されます。(異なる属性にも一致するイベントを含めるようにこの操作セットを拡張できます。たとえば、特定のSQL文を含みますが、必ずしも同じECIDではないイベント)。
この操作セットは、「イベント・ログ」内の任意のイベントを右クリックし、「操作セット」>一致するECIDの追加>「ecid」の順に選択して定義します。図4-6を参照してください。
操作セットは、さらに、図4-7に示すイベント・ログ表上の「操作セットのみを表示」を選択して表示されます。操作セットが、範囲ナビゲータでどのように示されているかに注意してください。
サーブレットの呼び出しイベントを生成したリクエストの結果表示された実行フローの実行時トレイルは、追加イベント・タイプを含めて表示できます。たとえば、図4-8では、「イベント・タイプ」ブラウザを使用してすべてのWebLogic Serverイベント・タイプが追加され、イベントが発生順にリストされているときの操作セットを示します。(「開始時間」列の先頭を選択してイベントを発生順にソートできます。)
この例では、イベント・ログに表示される実行フローの一部が示されています。
サーブレットのURIが呼び出されます。
サーブレットはEJBを使用するため、データベースへのアクセスが必要となります。
JDBC接続を取得し、トランザクションが開始されます。
操作セットは、実行フローの時間間隔を制約し、追加プロデューサからの相関イベントを追加して、さらに分析できます。表示されたイベントために時間間隔を制約することにより、操作セットと同時に発生したイベント・ログにイベントを追加できます。これよって、パフォーマンスの問題を診断するために役に立つ実行コンテキストの詳細を追加できます。
範囲ナビゲータで範囲選択バーを選択して時間間隔を制約することができます。このバーをポインタでグラブし、内側または外側にドラッグして、イベント・ログに表示されるイベントの範囲を変更することができます。図4-9で示すように、ナビゲータのいずれかの先端上マウスポインタを乗せると、範囲選択バーがアクティブ化されます。
HotSpotなどの追加プロデューサからのイベントは「イベント・タイプ」ブラウザから選択できます。JVMイベントにはECID属性がないため、そのイベントを操作セットのWLDFイベントに含めることはできません。したがって、JVMイベントを表示するには、「操作セットのみを表示」の選択を解除する必要があります。
この時点でイベント・ログに表示されるイベントは、選択した時間間隔で発生されたイベントであり、他との関連はありません。図4-10では、JDBCイベントおよびJVMイベントのみの選択によるJDBCアクティビティのドリルダウンを示します。選択した時間間隔でJDBCイベントのフローと同時に発生するJVMアクティビティを表示するために、イベント・ログが更新され、時系列順に表示されます。
オペレーティング・システムのtemp
ディレクトリに作成される一時JFRファイルは、JVMによって直接管理されます。WLDFはこれらのファイルを制御しません。(デフォルトでは、Javaフライト・レコーダに関連するWLDFの一時ファイルは、DOMAIN_HOME
/servers/
SERVER_NAME
/server/logs/diagnostic_images
ディレクトリに格納されます。)
ただし、JVMがその一時ファイルを格納する場所は、Javaフライト・レコーダ起動時に次のコマンドライン・オプションを使用して変更できます。ここで、path
は優先場所を示します。
-XX:FlightRecorderOptions=repository=path
Javaフライト・レコーダの構成設定の詳細は、次の場所にある『Java Flight Recorderランタイム・ガイド』を参照してください。