| Oracle® Fusion Middlewareパフォーマンスおよびチューニング・ガイド 11gリリース1（11.1.1） B61006-01 |
|
 戻る |
 次へ |
Oracle Dynamic Monitoring Service（DMS）を使用すると、アプリケーション開発者、サポート・アナリスト、システム管理者、その他のユーザーは、アプリケーション固有のパフォーマンス情報を測定できます。この付録では、DMSについて説明し、サンプル・アプリケーションを通じてDMSを使用したJavaアプリケーションのインスツルメント方法を示します。
|
注意: Oracle Fusion Middlewareには、組込みメトリックがいくつか用意されています。DMSを使用してアプリケーションのインスツルメントを行うと、この組込みメトリックのセットに新しいメトリックが追加されます。 |
この付録の内容は次のとおりです。
Dynamic Monitoring Service（DMS）APIを使用すると、Oracle Fusion Middlewareアプリケーションにパフォーマンス・インスツルメンテーションを追加できます。実行時、Oracle Fusion MiddlewareはDMSメトリックと呼ばれるパフォーマンス情報を収集します。この情報を基に、開発者、システム管理者およびサポート・アナリストは、システム・パフォーマンスの分析やシステム・ステータスの監視を行います。
この項の内容は次のとおりです。
Oracle Fusion Middlewareコンポーネントには、定義済メトリックがいくつか用意されています。個々のパフォーマンス・メトリックの定義を調べるには、Fusion Middleware Controlオンライン・ヘルプを使用します。メトリック情報へのアクセスの詳細は、4.2.1項「Fusion Middleware Controlを使用したパフォーマンス・メトリックの表示」を参照してください。
DMSインスツルメンテーションとは、アプリケーション・コードにDMSコールを挿入するときに使用するプロセスを指します。DMS APIを使用すると、アプリケーションのパフォーマンス情報の収集および分析が行えます。
DMSメトリックを作成するには、イベントの発生、重要な時間間隔の開始および終了、または事前に計算された値の状態の変化をDMSに通知するDMS APIコールを追加します。実行時、DMSはメトリックをメモリーに格納し、ユーザーがそのメトリックを保存または表示できるようにします。
|
注意: dms.jarファイルがアプリケーションのクラスパスに存在することを確認してください。
デフォルトでは、 |
Oracle Fusion Middlewareには、組込みメトリックが用意されています。アプリケーションにDMSコールを追加すると、この組込みメトリックのセットが拡張されます。DMSコールによってアプリケーションのインスツルメントを行う際には、組込みメトリックで使用されているのと同じAPIを使用します。また、メトリックの保存および表示には、組込みメトリックの場合に使用するのと同じモニタリング・ツールを使用します。
oracle.dms.trace.triggered.enableは、Oracle Fusion Middleware 11gリリース1（11.1.1）ではデフォルトでTRUEに設定されていますが、11gリリース1（11.1.1.2.0）ではデフォルトでFALSEに設定されていますので注意してください。
詳細は、A.2項「JavaアプリケーションへのDMSインスツルメンテーションの追加」を参照してください。
DMSメトリックの監視とは、パフォーマンス・メトリックを取得するプロセスを指します。アプリケーションの実行時、DMSはメトリックをメモリーに格納します。ユーザーは、コンソールで、またはWebブラウザを使用してメトリックを表示できます。
Oracle Fusion Middlewareは、DMSメトリックの表示および保存が可能なランタイム・ツールをいくつか備えています。たとえば、WLSTコマンド（displayMetricTableNames、displayMetricTables、dumpMetricsなどのサブコマンドを使用）やスパイ・サーブレットなどです。
|
注意: WLSTコマンドを使用するには、コンポーネントがインストールされているOracleホームからWLSTを起動する必要があります。詳細は、『Oracle Fusion Middleware管理者ガイド』のカスタムWLSTコマンドの使用に関する項を参照してください。 |
例A-1は、wlst dumpMetricsの出力を示しています。
例A-1 dmsDemoアプリケーションに対するwlst dumpMetricsのサンプル出力
/dmsDemo [type=n/a] /dmsDemo/BasicBinomial [type=MathSeries] computeSeries.active: n threads computeSeries.avg: n msecs computeSeries.completed: n ops computeSeries.maxActive: n threads computeSeries.maxTime: n msecs computeSeries.minTime: n msecs computeSeries.time: n msecs lastComputed.value: n loops.count: n ops
この項では、DMSに関連した用語を紹介します。この項の内容は次のとおりです。
図A-1は、この章で説明するデモ・アプリケーションのメトリック、および例A-1に示すメトリックに対応する、DMSメトリックのセットの構成を表したものです。
DMSメトリックは、開発者、システム管理者およびサポート・アナリストがシステム・パフォーマンスの分析やシステム・ステータスの監視を行うのに役立つパフォーマンス情報を提供します。
DMS Sensorは、パフォーマンス・データを測定します。このSensorによって、メトリックのセットの定義および収集が可能になります。メトリックには、Sensorに常に含まれるものとオプションとして含まれるものがあります。
DMSには3種類のSensorがあります。
DMS PhaseEvent Sensorは、コード内の特定セクションの開始から終了までにかかる時間を測定します。あるメソッドまたはコード・ブロックの処理にかかる時間を追跡する場合は、PhaseEvent Sensorを使用します。
DMSでは、PhaseEvent Sensorの処理にかかる平均時間、最大時間、最小時間など、PhaseEventに関連するオプションのメトリックを計算できます。
表A-1に、PhaseEvent Sensorで使用可能なメトリックを示します。
表A-1 DMS PhaseEvent Sensorのメトリック
| メトリック | 説明 |
|---|---|
|
|
フェーズ デフォルトのメトリック: |
|
|
プロセスの開始以降にフェーズ オプションのメトリック |
|
|
フェーズ オプションのメトリック |
|
|
フェーズ オプションのメトリック |
|
|
フェーズ オプションのメトリック |
|
|
DMS統計の収集時にフェーズ オプションのメトリック |
|
|
プロセスの開始以降に、フェーズ オプションのメトリック |
DMS Event Sensorは、システム・イベントをカウントします。継続時間の短いシステム・イベントを追跡する場合や、イベントの継続時間よりもイベントの発生が重要な場合は、DMS Event Sensorを使用します。
表A-2に、Event Sensor関連のメトリックを示します。
DMS State Sensorは、Javaプリミティブの値またはJavaオブジェクトのコンテンツを追跡します。サポートされている型は、integer、double、longおよびobjectです。システムのステータス情報を追跡する場合や、イベントに関係のないパフォーマンス・メトリックが必要な場合は、State Sensorを使用します。たとえば、State Sensorを使用して、キューの長さ、プール・サイズ、バッファ・サイズまたはホスト名を追跡します。State Sensorには、事前に計算された値を割り当てます。
表A-3に、State Sensorのメトリックを示します。State Sensorは、デフォルトのメトリックvalueおよびオプションのメトリックをサポートします。オプションのminValueメトリックおよびmaxValueメトリックは、State Sensorが（integer型、double型、long型などの）数値のJavaプリミティブを表す場合にのみ適用されます。
表A-3 DMS State Sensorのメトリック
| メトリック | 説明 |
|---|---|
|
|
デフォルト: |
|
|
オプションのメトリック |
|
|
起動後の オプションのメトリック |
|
|
起動後のこの オプションのメトリック |
DMS Nounはパフォーマンス・データを編成します。Sensorは、関連付けられたメトリックとともに、Nounに従って階層に編成されます。Nounを使用すると、ファイル・システムのディレクトリ構造と同様の方法で、DMSメトリックを編成できます。たとえば、Nounは、クラス、メソッド、オブジェクト、キュー、接続、アプリケーション、データベース、その他の測定の対象を表すことができます。
Nounタイプは、収集対象となるメトリックのセットを表す名前です。
Nounのネーミング方式では階層のルートに「/」を使用し、各Nounがルート、または親Nounの下にあるコンテナとして機能します。
DMSロールアップNounは、集計Nounのセットをリクエストするインスツルメンテーションを組み込んだときに、DMSによって生成されるNounです。ロールアップNounには、指定したNounタイプの子孫Noun内のSensorのセットからのメトリックが含まれます。ロールアップNounには、サマリー情報も含まれます。
DMSのNounおよびSensorを作成する際には、この項のガイドラインに従い、ユーザーが様々なアプリケーションやOracle Fusion Middlewareコンポーネント全体にわたってメトリックを簡単に理解できるようにしてください。
|
注意: このネーミング規則はガイドラインとして使用してください。どの規則にも例外が存在します。名前はできるだけ明確に定義してください。矛盾が生じた場合は、例外を設ける必要があります。 |
この項の内容は次のとおりです。
Noun名は、区切文字を含まない単純な文字列です。たとえば、BasicBinomialはNoun名です。Nounのフルネームは、その親のフルネーム、区切文字、Noun名で構成されます。たとえば、/dmsDemo/BasicBinomialはNounのフルネームです。
Sensor名は、「.」や派生を含まない単純な文字列です。たとえば、computeSeries、loopsおよびlastComputedはSensor名です。
Sensorのフルネームは、そのSensorが関連付けられたNounの名前、区切文字、Sensor名で構成されます。たとえば、/dmsDemo/BasicBinomial/computeSeries、/dmsDemo/BasicBinomial/loops、/dmsDemo/BasicBinomial/lastComputedなどです。
DMSメトリック名は、Sensor名、「.」、メトリックで構成されます。たとえば、computeSeries.time、loops.countおよびlastComputed.valueは有効なDMSメトリック名です。
|
注意: 接尾辞.time、.countおよび.valueは変更できません。ただし、Sensor名およびNoun名は必要に応じて変更可能です。 |
DMSの名前はできるだけ簡潔にしてください。また、NounやSensorの名前を定義する場合は、可能であれば特殊文字（空白、スラッシュ、ピリオド、カッコ、カンマ、制御文字など）を使用しないでください。
表A-5に、DMSの名前の中で特殊文字のかわりに使用する代替文字を示します。
表A-5 DMSの名前の中で特殊文字のかわりに使用する代替文字
| 文字 | DMSの代替文字 |
|---|---|
|
空白 |
アンダースコア: |
|
ピリオド: |
アンダースコア: |
|
制御文字 |
アンダースコア: |
|
より小さい: |
開きカッコ: |
|
より大きい: |
閉じカッコ: |
|
アンパサンド: |
カレット: |
|
二重引用符: |
バッククォート: |
|
一重引用符: |
バッククォート: |
|
注意: Oracle Fusion Middlewareには、組込みメトリックがいくつか用意されています。Oracle Fusion Middlewareの組込みメトリックが、このDMSネーミング規則に常に従っているとはかぎりません。 |
Nounには、特定のエンティティを識別する名前を付けてください。
Nounタイプには、収集対象となるメトリックのセットを明確に表す名前を使用する必要があります。たとえば、ServletというNounタイプは、そのNounで特定のサーブレットに固有のメトリックを収集することを示します。
Nounタイプ名は、他のDMSの名前と区別するために大文字で始めてください。同じタイプのNounはすべて、同じSensorのセットを持ちます。
次のリストは、DMS Sensorのネーミング規則をまとめたものです。
Sensor名は、簡潔で説明的なものにしてください。冗長になるのを避けるため、Sensor名には、Noun名の一部やNounタイプを含めないようにします。
Sensor名には、個々のメトリックの値を含めないでください。
Sensorを説明するために複数の単語を組み合せる必要がある場合は、最初の単語は小文字で、以降の単語は大文字で始めます。たとえば、computeSeriesのようになります。
一般に、Sensor名に「/」を使用することは避けてください。ただし、「/」を含む名前を使用することに意味がある場合もあります。Noun名またはSensor名に「/」を使用した場合は、そのSensorをDMSメソッドの文字列で使用する際に、かわりの区切文字として、パスにまったく存在しない「,」や「_」などを使用する必要があります。そうすることで、「/」は区切文字ではなく、Noun名またはSensor名の一部であることが正しく認識されるようになります。
たとえば、次のような名前の子Nounがあるとします。
examples/jsp/num/numguess.jsp
これは、次のような文字列を使用して検索できます。
,default,WEBs,defaultWebApp,JSPs,example/jsp/num/numguess.jsp,service
この場合の区切文字は「,」です。
Event SensorおよびPhaseEvent Sensorの名前は、英単語を動詞+名詞という形式で組み合せて定義します。たとえば、activateInstanceやrunMethodのようになります。PhaseEventによって関数、メソッドまたはコード・ブロックを監視する場合は、実行されるタスクをできるだけ明確に反映した名前を使用します。
State Sensorの名前には名詞を使用します。場合によっては、このState Sensorで追跡する値の内容を説明する形容詞が前に付きます。たとえば、lastComputed、totalMemory、port、availableThreads、activeInstancesのようになります。
混乱を避けるため、.time、.value、.avgなどの文字列をSensor名に使用しないでください。表A-1、表A-2および表A-3に示したとおり、これらはSensorメトリックの名前であるためです。
Javaアプリケーションのパフォーマンス情報を収集するには、DMSインスツルメンテーションを既存のアプリケーションに追加するか、DMSインスツルメンテーションを含む新しいアプリケーションを作成します。
この章に示すDMSのサンプルは、Oracle Technology Networkからダウンロードできます。
http://www.oracle.com/technology/tech/java/oc4j/demos/904/DMS/dmsDemo.zip
dmsDemo.zipファイルには、すぐにデプロイ可能な.earファイル、およびビルド手順付きのソース・コードが含まれています。このデモには、BasicBinomial.javaとImprovedBinomial.javaの2つのサーブレットが含まれています。
BasicBinomialサーブレットは、DMS APIを使用してDMS NounおよびSensorを追加する方法を示します。
ImprovedBinomialサーブレットはBasicBinomialサーブレットを拡張したもので、改善されたコードをBasicBinomialと比較して示します。ImprovedBinomialサーブレットは、さらに詳細な情報を収集するための、より負荷のかかるメトリックの追加方法についても示しています。
この章に示す例の完全なコードは、サンプル・コードを参照してください。
DMSインスツルメンテーションを使用するには、次の手順を実行してDMSコールを追加します。
DMSを使用するには、DMS importを追加する必要があります。次の例は、サンプル・アプリケーションBasicBinomial.javaで必要なimportを示しています。
import oracle.dms.instrument.DMSConsole; import oracle.dms.instrument.Event; import oracle.dms.instrument.Noun; import oracle.dms.instrument.PhaseEvent; import oracle.dms.instrument.State; import oracle.dms.instrument.Sensor;
BasicBinomialサーブレットおよびImprovedBinomialサーブレットを含むサンプル・アプリケーションでは、Nounが次のように編成されます。
例A-2は、BasicBinomial.javaのコードのあるセクションを示しています。ここでは、Noun.createをコールして、/dmsDemo Nounルート、および/dmsDemoの子であるBasicBinomial Nounを作成しています。
例A-2 BasicBinomial.java: Noun.createを使用したSensorの編成
private Noun binRoot; // Container for Binomial series DMS metrics
Noun base = Noun.create("/dmsDemo");
binRoot = Noun.create(base, "BasicBinomial", "MathSeries");
/dmsDemoは、サンプルの二項アプリケーションのNounルートです。先頭のスラッシュは、これがルートであることを示しています。
BasicBinomial Nounは、MathSeriesというNounタイプ（createメソッドの3番目のパラメータ）付きで作成されます。Nounタイプは、収集対象となるメトリックのセットを表す名前です。この場合、MathSeriesはサンプルの二項アプリケーションについてメトリックを収集することを示します。
同じ二項アプリケーションに含まれるImprovedBinomialサーブレットにも、同様の行があります（例A-3）。唯一の違いは、BasicBinomialではなく、ImprovedBinomialという名前の子Nounが作成されることです。
例A-3 ImprovedBinomial.java: Noun.createを使用したSensorの編成
private Noun binRoot; // Container for Binomial series DMS metrics
Noun base = Noun.create("/dmsDemo");
binRoot = Noun.create(base, "ImprovedBinomial", "MathSeries");
dmsDemo Nounは、子がすべてNounであるため、Nounタイプ付きで作成されないことに注意してください。子Sensorはありません。
スパイ・サーブレットは、同じタイプのすべてのNounを表の行として表示します。この表の名前がNounタイプです。メトリックは、表の列として表されます。
Nounタイプは、NounがSensorを直接含む場合にのみ使用してください。dmsDemoのように、他のNounのみを含み、Sensorを直接含まない場合、スパイ・サーブレットはNounタイプをメトリック表として表示します（ただし、メトリックはありません）。
dmsDemo NounはNoun（BasicBinomial）を含んでいますが、直接のSensorは含んでいません。そのようなNounにNounタイプがない場合、スパイ・サーブレットはNounに関連付けられたメトリック表を表示しません。
一般に、NounおよびNounタイプにはそれぞれ異なる名前を付けて、同じレベルにある同じタイプのNounが論理階層を構成するようにしてください。たとえば、dmsDemoアプリケーションには、BasicBinomialとImprovedBinomialの2つのサーブレットがあります。DMSインスツルメンテーションでは、どちらのサーブレットにもNounタイプMathSeriesを使用します。このNounタイプは、どちらのサーブレットに対しても同じ階層レベルの/dmsDemoの下に作成されます。この規則を順守することで、生成されるメトリック表が理解しやすくなります。また、レポート作成プロセスにおける最小限の情報の漏れも防ぐことができます。
コードの一部の実行にかかる時間を測定するメトリックを作成するには、PhaseEvent Sensorを使用します。
例A-4は、computeSeriesというPhaseEvent Sensorを宣言して作成するDMSコールを示しています。このコードは、/dmsDemo/BasicBinomial/computeSeries.timeという名前のDMSメトリックを定義します。
例A-4 PhaseEvent Sensorの定義
private PhaseEvent binComp; // Time to compute Binomial series ... binComp = PhaseEvent.create(binRoot, "computeSeries", "Time to compute a Binomial series"); binComp.deriveMetric(Sensor.all);
PhaseEvent Sensorは、デフォルトのメトリック.time（PhaseEvent startコールからPhaseEvent stopコールまでの合計時間を示す）とともに、オプションのメトリックのセットをサポートします。PhaseEvent Sensorのオプションのメトリックは、個別に、あるいは完全なメトリックのセットとして得ることができます。表A-1に、PhaseEvent Sensorで使用可能なメトリックをまとめてあります。例A-4のbinComp.deriveMetric(Sensor.all)コールによって、サポートされるオプションのメトリックがすべて計算されレポートされるようになります。
|
注意: オプションのメトリックを追加する場合は、メソッドderiveMetric(Sensor.all)を使用することをお薦めします。Sensor.allとともにこのメソッドを使用すれば、すべてのメトリックを追加できます。この方法が推奨されるのは、今後リリースされるOracle Fusion Middlewareでオプションのメトリックが変更される可能性があるためです。また、このメトリックは効率的に計算でき、パフォーマンスの評価に役立ちます。 |
PhaseEvent Sensorを使用するには、アプリケーションで、startメソッドをコールしてフェーズの開始を示し、続いてstopソッドをコールしてフェーズの完了を示します。
例A-5は、startメソッドおよびstopメソッドを使用して/dmsDemo/BasicBinomial/computeSeries.timeメトリックを測定するBasicBinomial.javaのコードを示しています。PhaseEvent startメソッドから返されるtokenという名前のlong値は、対応するPhaseEvent stopメソッドに渡す必要があります。この値は、開始時刻を表すタイムスタンプです。この値をstopソッドに渡すことにより、DMSでPhaseEventの継続時間を計算できます。
|
注意: PhaseEventを確実に停止させるには、例A-5に示すように、各PhaseEventstartメソッドを測定対象のコードとともにtryブロックに置き、PhaseEvent stopメソッドを対応するfinallyブロックに置く必要があります。 |
例A-5 PhaseEvent Sensorでのstartおよびstopの使用
long token = 0; // DMS
try {
token = binComp.start(); // DMS
BigInteger bins[] = bin(length);
out.println("<H2>Binomial series for " + length + "</H2>");
for (int i = 0; i < length; i++)
out.println("<br>" + bins[i]);
}
finally {
binComp.stop(token); // DMS
out.close();
}
例A-5は、フェーズが開始するたびに停止される（finally句にstopメソッドがあるため）ようインスツルメントしたコードを示しています。こうすることで、Phase Sensorの暴走を防止できます。ただし、例外をスローするのに必要な時間が、フェーズ統計に算入される可能性があります。例外処理がPhaseEventに影響を与えるのを避けるには、例A-6に示すように、abortメソッドを使用します。
例A-6は、正しく停止されなかったフェーズをクローズすることのできるサンプル・コードを示しています。abortコールによって、該当のstartに対応する統計が削除されます。削除された統計は、メトリックの計算に算入されません。
例A-6 PhaseEvent Sensorでのabortの使用
PhaseEvent pe = heavyPhase(param);
long token1 = 0;
long token2 = 0;
boolean stopped = false;
try {
token1 = binComp.start();
if (pe != null) token2 = pe.start();
BigInteger bins[] = bin(length);
out.println("<H2>ImprovedBinomial series for " + length + "</H2>");
for (int i = 0; i < length; i++)
out.println("<br>" + bins[i]);
if (pe != null) pe.stop(token2);
binComp.stop(token1);
stopped = true;
}
finally {
if (!stopped) {
if (pe != null) pe.abort(token2);
binComp.abort(token1);
}
}
イベントの発生をカウントするメトリックを作成するには、Event Sensorを定義して使用します。
例A-7は、Event Sensorを定義するDMSコールを示しています。このコードは、カウンタを割り当てて、/dmsDemo/BasicBinomial/loops.countという名前のDMSメトリックを定義します。
アプリケーションでEvent Sensorのoccurredメソッドがコールされるたびに、DMSはカウンタの値を増やします。例A-8は、/dmsDemo/BasicBinomial/loops.countメトリックの値を増やす、Event Sensorのoccurredコールを示しています。
DMSは、State Sensorを使用してステータス情報を取得します。State Sensorは、Javaプリミティブの値またはJavaオブジェクトのコンテンツを追跡します。サポートされている型はinteger、double、longおよびobjectで、これらはcreateメソッドの3番目の引数として指定されます。JavaプリミティブのState Sensorが不正な型で更新された場合、DMSは指定された値を正しい型に変換しようとします。object型のState Sensorの場合、DMSはオブジェクトへの参照を格納し、DMS値をサンプリングする際に、そのオブジェクトに対してデフォルトでtoStringをコールします。
ステータス情報を記録するメトリックを作成するには、State Sensorを定義して使用します。
State Sensorは、デフォルトのメトリックvalueおよびオプションのメトリックをサポートします。オプションのminValueメトリックおよびmaxValueメトリックは、State Sensorに対し、State Sensorが（integer型、double型、long型などの）数値のJavaプリミティブを表す場合にのみ定義できます。表A-3に、State Sensorで使用可能なメトリックをまとめてあります。例A-4は、オプションのメトリックを有効にする方法を示しています。
例A-9は、State Sensorを宣言して作成するDMSコールを示しています。このコードは、/dmsDemo/BasicBinomial/lastComputed.valueという名前のDMSメトリックを定義します。
例A-9 State Sensorの定義
private State binLast; // Value of the last computed element in series.
...
binLast = State.create(binRoot, "lastComputed", State.OBJECT, "",
"Value of last computed series element");
State Sensorを定義する際に、State Sensorに値が関連付けられていない場合は、createメソッドの4番目の引数に空の文字列を使用します。それ以外の場合は、適切な値の文字列を使用します（例A-9を参照）。State Sensorは、初期値なしで作成されます。State Sensorが初期化されたかどうかを確認する必要がある場合は、isInitializedメソッドを使用します。
オブジェクトへの参照ではなく、オブジェクトの文字列の値が格納されるようにするには、値TRUEを指定したsetCopyメソッドを使用します。こうすると、オブジェクトへの参照がメトリック値として使用されるかわりに、オブジェクトに対してtoStringをコールした結果が格納されます。
アプリケーションでState Sensorのupdateメソッドがコールされると、DMSはState Sensorの値を更新します。例A-10は、/dmsDemo/BasicBinomial/lastComputed.valueメトリックを更新する、State Sensorのupdateコールを示しています。
Javaアプリケーションに追加するメトリックは、その精度をテストして検証する必要があります。この項の内容は次のとおりです。
新しいメトリックを検証してテストするには、wlstやその他の使用可能なDMSモニタリング・ツールを使用します。
新しいメトリックについて、次のことを検証してください。
予期したメトリックがディスプレイに表示されるかどうか。これをテストするには、コードを調べて、DMSインスツルメンテーションによって追加されたすべてのメトリックの名前が、ディスプレイまたは保存されたメトリックのセットに表示されていることを確認します。
予期しないメトリックがディスプレイに表示されないかどうか。追加を予定していたメトリックのみが追加されていることを確認します。
表示されるメトリック値が有効な範囲内にあるかどうか。通常、メトリックには上限および下限を設定できます。メトリックの範囲を設定した場合は、レポートされるメトリック値をテストして、その範囲を超えないことを確認します。
たとえば、プール・サイズを測定するメトリックでは、負の値がレポートされることはありません。
新しいメトリックが必要であることを確認します。たとえば、継続時間がきわめて短いイベントを常に測定するPhaseEventを追加する場合は、そのメトリックをEventメトリックに変更することを検討するか、そのメトリックを削除します。
新しいメトリックが正確であることを確認します。DMSメトリックを使用するほとんどのアプリケーションでは、DMSインスツルメンテーションを追加する際に、パフォーマンス・コストよりも正確さが重要視されます。新しいDMSメトリックは、信頼できる有用な情報を提供するものであることが必要です。
正確性をテストするのは難しいこともあります。ただし、特定のメトリックを測定する別の方法がある場合は、それを使用してメトリック値を検証します。たとえば、既知の数のリクエストをサーバーへ送信して処理にかかる合計時間を測定する場合、関連するメトリックの適切な値を予測し、それらを実際に監視された値と比較します。また、ログ・ファイルまたはコンソールに書き込まれたレコードを調べれば、Event Sensorのcountメトリックを検証できます。
メトリックに適用される時間測定の不正確さをチェックします。時間測定が不正確になる可能性があるのは、低分解能のクロックを使用して短い時間間隔でメトリックを測定した場合です。たとえば、Windowsシステムでは、デフォルトのJavaのクロックは15ミリ秒に1回しか進みません。このようなシステムで短時間のイベントについてレポートされるDMSメトリックは、注意深く分析する必要があります。この問題を解決するには、高分解能のクロックの使用を検討してください。
DMSメトリックの使用は、アプリケーションのパフォーマンスに少なからず影響を与えます。メトリックを追加する場合は、次のことに注意してください。
メトリックを計算して格納するために必要な処理は、アプリケーションの実行速度が低下する原因となります。DMSは高速ですが、多少のパフォーマンス・コストが生じることがあります。また、開発者がDMS APIを非効率的に使用するのを防ぐことはできません。そこで、DMSインスツルメンテーションを追加する前に、無理のない予測を立ててください。実装の完了後、実際のコストを測定して予測と比較します。測定値が予測と一致するまで、インスツルメンテーションを変更してパフォーマンスへの影響を軽減してください。
DMSには、メトリックの使用を制御するのに役立つDMSConsole.getSensorWeightメソッドが用意されています。中心的な設定は推奨される測定レベルであり、DMSで規定されるものではありません。どのメトリックを含めるかを制御するには、実行時にSensorWeightの値をテストして、DMSコールを行うかどうかを判断する必要があります。詳細は、A.5項「DMS Sensor Weightを使用した条件付きインスツルメンテーション」を参照してください。
DMSインスツルメンテーションを既存のパッケージに統合する場合や、新しい機能を実装する場合は、それまで稼働していたシステムを保護することを検討してください。たとえば、新しいDMSメトリックの有効/無効を切り替えるオプションを含めることができます。
DMSを有効にした場合と有効にしていない場合の両方についてパフォーマンス・テストを実行します。DMSを有効にして行ったテストの結果が受け入れられない場合は、メトリックの設計または実装をやりなおしてください。
DMSメトリックは、DMSレポートへのユーザー・ベースのアクセスをサポートしません。DMSメトリックを定義して使用する場合、DMSメトリックへのアクセス権限を持つ管理者であれば、誰でもそのメトリックを使用できます。したがって、DMSメトリックを追加する際に、顧客の機密情報をメトリックに含めるのは避けてください。
条件付きでインスツルメンテーションを制限するには、DMS Sensor Weight機能を使用します。Sensor Weight機能を使用する際は、Sensor Weightが特定の値に設定されている場合にのみ、高コストのインスツルメンテーションをアプリケーションで実行するよう指定します。この機能を使用すれば、デバッグのみに必要とされるような高コストのメトリックを含めることができます。
例A-11は、DMSConsole.getSensorWeightを使用する方法、およびオプションでメトリックを定義して使用する方法を示しています。Nounのコンテンツ（Sensorまたはメトリック）を制御する目的でSensorWeightを使用しないでください。SensorWeightを使用するのは、（下の例に示すように）Nounの存在を制御するため、そして何よりも特定のタイプのNounの存在を制御するためです。
Sensor Weightは、コマンドラインでoracle.dms.sensorsプロパティを使用してグローバルに設定します。このプロパティの設定には、起動オプションを使用します。このプロパティに指定できる値は、none、normal、heavyおよびallです。
例A-11 SensorWeightを使用した条件付きインスツルメンテーション
/* DMS Method
*
* If the SensorWeight is high enough, return a phase with the
* parameter in the name. Otherwise, return null.
*/
PhaseEvent heavyPhase(String param) {
PhaseEvent pe = null;
if (DMSConsole.getSensorWeight() > DMSConsole.NORMAL) {
Noun base = Noun.create(binRoot, param, "MathSeries");
pe = PhaseEvent.create(base, "computeSeries",
"Time to compute a Binomial series");
pe.deriveMetric(Sensor.all);
}
return pe;
}
Javaアプリケーションでは、次のメソッドを使用してDMSメトリックをファイルへダンプします。
次のコードを使用すると、指定したファイルに現行のメトリックを追加したり、指定したファイルの内容を現行のメトリックに置き換えることができます。
DMSConsole cons2 = new DMSConsole();
DMSConsole.dump("dmsmathseries.log", "xml", true);
最初の引数にはファイルのパス名、2番目の引数には出力形式を指定します。3番目の引数には、この出力をファイルに追加するか、あるいはファイルの内容を出力に置き換えるかを指定します。
|
警告: このプロセスでは、JVMのDMS情報がすべてダンプされます。JVMが複数のアプリケーション（J2EEなど）を実行している場合は、すべてのアプリケーションのすべてのメトリックがダンプされます。 |
Sensor抽象クラスは、PhaseEvent Sensor、Event SensorおよびState Sensorを制御するためのメソッドを提供します。resetメソッドは、Sensorのメトリックを初期値にリセットします。getResetTimeメソッドは、Sensorがリセットされたかどうかを判別します。destroyメソッドは、SensorをDMSから削除して、その基礎となるリソースへの参照を解放します。
|
注意: これらのメソッドを、組込みメトリックをリセットまたは破棄するために使用しないでください。resetメソッドおよびdestroyメソッドは、ユーザーが作成したメトリックに対して使用することを想定しています。これらのメソッドを内部の組込みメトリックに対して使用すると、Fusion Middleware ControlやOracle Fusion Middlewareのその他の管理機能が予期しない値をレポートしたり、予期しない動作をしたりすることがあります。 |
DMSメトリックにはグローバルなネームスペースがあります。新しいNoun Sensor（PhaseEvent、EventまたはState）を作成する場合は、そのフルネームが、Oracleの組込みメトリックまたはその他のアプリケーションで使用される名前と競合しないようにする必要があります。したがって、アプリケーションにはそのフルネームを含むルートNounを作成してください。そうすることで、ネームスペースの競合を回避できます。
すべてのPhaseEventが停止していることを確認します。測定対象のコード・ブロックがtryブロック内にない場合は、これをPhaseEventのstartを含むtryブロックに置きます。PhaseEventのstopはfinallyブロックに置きます。または、例A-6のように、finallyブロックでabortメソッドを使用します。
DMSネーミング規則に従います。
DMSのSensorまたはNounを複数回作成することは避けます。DMS APIを使用すればこれが可能であり、複数のオブジェクトが作成されることはなくなりますが、後で作成を試みるたびにDMSによって参照が実行されます。そのため、可能なかぎりSensorとNounは静的初期化中に定義するか、サーブレットの場合はinitメソッドで定義してください。
Sensorを含む各Nounにタイプを割り当てます。タイプを割り当てない場合は、値n/a（使用不可）が割り当てられます。タイプにn/aが指定されたNounは、スパイ・サーブレットでは表示されません。
PhaseEventは、実行コストが高く、特定の状況下で実行にかなりの時間がかかるコードのセクションを測定する場合にのみ使用します。コードの実行に著しく時間がかかることがない場合は、Eventメトリックを使用するか、PhaseEventを削除します。
DMS APIのコールはスレッドセーフであり、競合やアクセスの不具合を回避するために十分な同期が行われます。
J2EEアプリケーションでDMSコンソールのライフサイクルを制御しないでください。DMSコンソールのライフサイクルは、J2EEコンテナによって管理されます。DMSはJ2EEサーバーのJVMに対してグローバルであるため、DMSに加えられた変更はそのJ2EEコンテナで実行されているすべてのアプリケーションに影響を与える可能性があります。
|
注意: Java APIで生成される実行コンテキスト文字列の先頭部分はIPアドレスの形式を取っており、C APIで生成される文字列とは異なります。問題の発生を防止するため、必ず単一のリクエスト/トランザクションを通して同じECIDが使用されるようにしてください。ECIDは、一貫して使用されるかぎり、どのような形式でもかまいません。 |
DMSインスツルメンテーションを追加する場合は、新しいメトリックの要件を慎重に検討してください。作成したコードが予想どおり機能していることを検証するのに十分な数のメトリックを追加することが重要です。
DMSメトリックを追加する場合は、次のガイドラインに従ってください。
目的のコード・ブロックまたはモジュールについて、システムでの処理に要した時間の概要のみを提供するPhaseEvent Sensorを追加します。すべてのメソッド・コール、または検証の対象となるコードやモジュールのすべての個別フェーズについてパフォーマンス・データを収集する必要はありません。
目的のコード内から制御対象外の外部コードをコールし、その外部コードの処理に長時間かかることが予想される場合は、PhaseEvent Sensorを追加して、外部コードの開始および完了を追跡します。
これらのガイドラインに従ってPhaseEventメトリックを追加すると、次の利点が得られます。
DMSで収集する情報の量を制限できます。
システムの分析担当者は、モジュールが期待されるランタイム・パフォーマンスを実現していることを実証できます。
DMSメトリックを参照するユーザーは、膨大な量のデータを表示せずにランタイム・パフォーマンスを検証できます。
システム・パフォーマンスの分析担当者は、目的のモジュールを、コストの高い、または失敗回数の多い他のシステム・モジュールから分離して追跡することができます。
デフォルトでは、DMSはPhaseEvent中に時間間隔を測定する際、システム・クロックを使用します。デフォルト・クロックのレポート精度は、ApacheなどのCプロセスではマイクロ秒、Javaプロセスではミリ秒です。パフォーマンス測定の精度向上のために、DMSはオプションで高分解能クロックをサポートしており、時間間隔をレポートする際の値をユーザーが選択できます。デフォルト・クロックを使用する場合よりも正確にPhaseEventの時間を測定する必要があるとき、またはシステムのデフォルト・クロックが分解能の要件に満たないときは、高分解能クロックを使用してください。
|
注意: デフォルト・クロック、高分解能クロックともに、分解能はプラットフォームに依存します。システムによっては、デフォルト・クロックの分解能では時間測定の要件を満たさない場合があります。特にWindowsプラットフォームでは、デフォルト・クロックは15ミリ秒に1回しか進みません。そのため、多くのユーザーがそれよりも高い精度を要求します。このようなシステムで短時間のイベントについてレポートされるDMSメトリックは、注意深く分析する必要があります。この問題を解決するには、高分解能のクロックの使用を検討してください。高分解能クロックの精度もプラットフォームに依存しますので注意してください。高分解能クロックを選択しても、ナノ秒単位の時間が正確にレポートされるという保証はありません。 |
この項の内容は次のとおりです。
高分解能クロックを選択すると、クロックを変更したプロセスで実行されているすべてのアプリケーションに対してクロックが変更されます。プロセスの起動オプションを制御するoracle.dms.clockプロパティおよびoracle.dms.clock.unitsプロパティを使用して、DMSクロックおよびレポートの値をグローバルに設定します。
たとえば、デフォルトの値で高分解能クロックを使用するには、Javaコマンドラインで次のプロパティを設定します。
-Doracle.dms.clock=highres
|
注意: 高分解能クロックを使用する場合、デフォルトの値はFusion Middleware Controlが予期している値（ミリ秒）と異なります。高分解能クロックを使用しているときに、Fusion Middleware Controlを正しく表示する必要がある場合は、単位のプロパティを次のように設定します。-Doracle.dms.clock.units=msecs |
表A-6に、oracle.dms.clockプロパティでサポートされる値を示します。
表A-7に、oracle.dms.clock.unitsプロパティでサポートされる値を示します。
表A-6 oracle.dms.clockプロパティの値
| 値 | 説明 |
|---|---|
|
DEFAULT |
デフォルト・クロックを使用することを指定します。デフォルト・クロックの場合、DMSはJavaコール デフォルト・クロックの単位のデフォルト値は、MSECSです。 |
|
HIGHRES |
Java Highresクロックは |
表A-7 oracle.dms.clock.unitsプロパティの値
| 値 | 説明 |
|---|---|
|
MSECS |
時間がミリ秒に変換され、msecsとしてレポートされることを指定します。ミリ秒は10-3秒です。 注意: これはデフォルト・クロックのデフォルト値です。 |
|
USECS |
時間がマイクロ秒に変換され、usecsとしてレポートされることを指定します。マイクロ秒は10-6秒です。 |
|
NSECS |
時間がナノ秒に変換され、nsecsとしてレポートされることを指定します。ナノ秒は10-9秒です。 注意: これは高分解能クロックのデフォルト値です。 |
高分解能のDMSクロックを使用するときは、次の点に注意してください。
oracle.dms.clockプロパティおよびoracle.dms.clock.unitsプロパティを設定する際には、大文字と小文字を自由に組み合せて、選択した値を指定することができます（大/小文字の区別はありません）。たとえば、高分解能クロックを選択する場合、highres、HIGHRES、HighResのどれも有効です。
DMSは、起動時にプロパティ値をチェックします。表A-6の値と一致しない値でクロックを設定すると、デフォルト・クロックが使用されます。oracle.dms.clockプロパティを設定していない場合も、デフォルト・クロックが使用されます。
指定したクロック単位のプロパティ値が表A-7の値と一致しない場合は、指定したクロックのデフォルトの単位が使用されます。oracle.dms.clock.unitsプロパティを設定していない場合は、指定したクロックのデフォルトの単位が使用されます。
Oracle HTTP Serverのパフォーマンスを測定する際のデフォルト・クロックの分解能はマイクロ秒（usecs）です。Oracle HTTP Serverで実行されているCプロセスを監視する場合は、オプションで、分解能がさらに高いクロックを選択できます。Oracle HTTP Serverで高分解能クロックを使用するには、httpd.confで構成オプションを設定するか、コマンドラインで環境変数を指定する必要があります。
表A-8に、Oracle HTTP ServerのDMSクロックを制御する環境変数を示します。表A-9に、Oracle HTTP ServerのDMSクロックを制御するhttpd.confの構成オプションを示します。コマンドライン・オプションとhttpd.confの構成オプションを両方とも設定した場合、コマンドラインで設定した値よりも構成オプションが優先されます。
表A-8 Oracle HTTP ServerのDMSクロック環境変数
| 環境変数 | 説明 |
|---|---|
|
DMS_CLOCK |
DMSの時間測定に使用するクロックを指定します。値はoracle.dms.clockと同様に解釈されます。 有効値: DEFAULT、HIGHRES |
|
DMS_CLOCK_UNITS |
DMSの時間測定値をレポートする単位を指定します。値はoracle.dms.clock.unitsと同様に解釈されます。 有効値: MSECS、NSECS、USECS デフォルト値: USECS |
表A-9 Oracle HTTP ServerのDMSクロック構成パラメータ
| パラメータ | 説明 |
|---|---|
|
|
Javaプロセスのoracle.dms.clockプロパティのように、Oracle HTTP Serverによって開始されるHTTPリスナー・プロセスのクロックを指定します。 有効値: DEFAULT、HIGHRES |
|
|
Javaプロセスのoracle.dms.clock.unitsプロパティのように、Oracle HTTP Serverによって開始されるHTTPリスナー・プロセスの時間単位を指定します。 有効値: MSECS、NSECS、USECS デフォルト値: USECS |
これらのオプションが指定されている場合、DMSは監視対象のすべてのOracle HTTP Serverプロセスに対して高分解能クロックを使用し、ミリ秒単位（msecs）で値をレポートします。
|
注意: Oracle HTTP Serverで高分解能クロックを使用する場合、デフォルトの単位はほとんどのプラットフォームでNSECSです。Fusion Middleware Controlを使用する必要がある場合は、単位としてUSECSが求められます。高分解能クロックを使用しているときに、Fusion Middleware Controlを正しく表示する必要がある場合は、単位のプロパティを次のように設定します。DmsClock=HIGHRES DmsClockUnits=USECS |
Oracle Fusion Middlewareには、メトリックの集計を指定できるDMSロールアップ機能が用意されています。このロールアップ機能を使用することで、DMSインスツルメンテーション時にメトリックの集計を指定できます。ロールアップの適用は、特定のNounタイプの子孫に対して指定します。ロールアップは、直接の子孫のみに適用することも、すべての子孫に適用することも可能です。例A-12は、図A-2のDMSツリーを生成するコードを示しています。タイプmyContainerのNounにはそれぞれ、percentageFull、close、openの各Sensorが含まれています（図A-2を参照）。
|
注意: 例A-12のコードでは、A.2.2.1項「Nounタイプの選択」で説明されている推奨事項に違反するNounツリー階層が生成されます。この例では、一部のNounが同じNounタイプの子孫および祖先を持つことに意味があります。この項で説明するロールアップ機能を使用すれば、他の方法では失われる可能性があるデータを収集できます。 |
例A-12 メトリックのNoun階層を作成するDMSサンプル・コード
// Create DMS Noun hierarchy for metrics Noun home = Noun.create(Noun.getRoot(), "Home", "myContainer"); Noun containers = Noun.create(home, "Containers", "myContainer"); Noun closets = Noun.create(containers, "Closets", "myContainer"); Noun bedrooms = Noun.create(closets, "Bedrooms", "myContainer"); Noun br1 = Noun.create(bedrooms, "BR1", "myContainer"); // Create a closet Noun and create Sensors for it Noun c1 = Noun.create(br1, "C1", "myContainer"); State percent = State.create(br1, "percentageFull", State.INTEGER, "percent", "percentage full"); Event close = Event.create(br1, "close", "container closed"); PhaseEvent open = PhaseEvent.create(br1, "open", "open container"); // Derive metrics for State and PhaseEvent Sensors percent.deriveMetric(Sensor.all); open.deriveMetric(Sensor.all);
図A-2は、子孫コンテナを持つツリーを示しています。BedroomsのBR1およびBR2の下にあるNoun C1およびC2は、タイプmyContainerです（myContainerメトリックの説明は図A-3を参照）。
ロールアップ機能を使用すると、子孫Nounのサマリーを集計できます。たとえば、例A-12に示したbedrooms Nounにロールアップ・コールを追加できます。BR1の下にあるmyContainerタイプ・メトリックを集計するには、次のコールを使用します。
br1.rollup("myContainer", Noun.DIRECT);
このコールによって、/Home/Containers/Closets/Bedrooms/BR1の下にmyContainer_rollupという名前のロールアップNounが作成されます。このロールアップNounには、percentageFull、close、openなど、関連付けられているNounと同じSensorが含まれます。
DMSロールアップ・メトリックでは、特定タイプのすべての子孫Noun内にあるSensorをロールアップすることも、直接の子孫Noun内にあるSensorのみをロールアップすることもできます。ロールアップ・コールにNoun.DIRECTを指定すると、指定されたタイプの直接の子孫Nounのみが集計されます。タイプmyContainerのすべての子孫Nounのメトリックを集計するには、次に示すようにNoun.ALLを使用してコールします。
closets.rollup("myContainer", Noun.ALL);
ロールアップ・メトリックには、その内容を集計したサマリー情報があります。表A-10に、各Sensorタイプで使用できる派生ロールアップ・メトリックを示します。
表A-10 ロールアップ・メトリックに含まれる派生メトリック
| メトリック | 説明 |
|---|---|
|
PhaseEvent |
PhaseEventロールアップ・メトリックの派生メトリックには、次のものがあります。
|
|
Event |
Eventロールアップ・メトリックの派生メトリックには、次のものがあります。
|
|
State |
Stateロールアップ・メトリックの派生メトリックには、次のものがあります。
|
|
ロールアップNounには、ロールアップの対象が直接の子孫のみかすべての子孫かをレポートする |
|
|
ロールアップNounには、ロールアップされているNounの数をレポートする |
|
|
ロールアップNounには、このロールアップNounのメトリックの集計に要した時間をレポートする |
例A-13は、/Home/Containers/ClosetsにあるmyContainerロールアップNounに対して作成されたサンプル・メトリックを示しています。
例A-13 テスト
myContainer_rollup descendent.value: all percentageFull.sum 40 percent percentageFull.avg 10.0 percent percentageFull.min 1 percent percentageFull.max 29 percent close.sum: 3 close.avg: 0.75 open.time: 871 msecs open.completed: 4 ops open.maxTime: 722 msecs open.minTime: 23 msecs open.avg: 217.7 msecs open.active: 0 rolled.value: 4 nouns refresh.maxActive: 1 threads refresh.active: 0 threads refresh.avg: 0.2857142857142857 msecs refresh.maxTime: 1 msecs refresh.minTime: 0 msecs refresh.completed: 7 ops refresh.time: 2 msecs
このメトリックはmyContainerメトリックと類似していることに注意してください。ロールアップ・メトリックには、主に次のような違いがあります。
ロールアップNounには、descendent、rolled、refreshの各メトリックがあります（詳細は表A-10を参照）。
percentageFull Stateには、valueメトリックではなく、sumメトリックおよびavgメトリックがあります。各メトリックの名前は、その内容を示しています。
close Eventには、countメトリックではなく、sumメトリックおよびavgメトリックがあります。各メトリックの名前は、その内容を示しています。
open PhaseEventには、maxActiveメトリックはありません。このコンテキストでは意味を持たないためです。
|
関連項目: Oracle Fusion Middleware DMSのJava APIリファレンス |
