Oracle Application Server パフォーマンス・ガイド 10gリリース3(10.1.3.1.0) B31836-02 |
|
Oracle Dynamic Monitoring Service(DMS)を使用すると、アプリケーション開発者、サポート・アナリスト、システム管理者およびその他のユーザーは、アプリケーション固有のパフォーマンス情報を測定できます。この章ではDMSについて説明し、DMSを使用したOracle Application Server Javaアプリケーションへのインストルメント方法について、サンプルのアプリケーションを使用して示します。
この章には、次の項が含まれています。
ダイナミック・モニタリング・サービス(DMS)APIを使用すると、Oracle Application Serverアプリケーションにパフォーマンス・インストルメントを追加できます。実行時、OC4JはDMSメトリックと呼ばれるパフォーマンス情報を収集します。開発者、システム管理者およびサポート・アナリストは、この情報を利用してシステム・パフォーマンスを分析したり、システムの状態を監視できます。
この項には、次の項目が含まれています。
OC4Jを含むOracle Application Serverコンポーネントには、いくつかの定義済メトリックが用意されています。定義済メトリックの一覧は、付録C「パフォーマンス・メトリック」を参照してください。
注意
DMS インストルメントとは、アプリケーション・コードにDMSコールを挿入するときに行う処理のことです。DMS APIを使用することで、アプリケーションのパフォーマンス情報を測定、収集および保存できます。
DMSメトリックを作成する場合、アプリケーション開発者は、イベントが発生するタイミング、重要な時間隔の開始と終了、および事前に処理済の値が変更されるタイミングなどをDMSに通知するDMS APIコールを追加します。実行時、DMSはメトリックをメモリーに格納し、ユーザーがそのメトリックを保存または表示できるようにします。
Oracle Application Serverには、組込みDMSメトリックが含まれています。アプリケーションにDMSコールを追加することで、この組込みメトリックのセットは拡張されます。DMSコールをアプリケーションにインストルメントする場合は、組込みメトリックで使用されているAPIと同じAPIを使用します。また、収集したメトリックを保存して表示するには、組込みメトリックで使用されているものと同じ監視ツールを使用します。
DMSメトリックの監視とは、パフォーマンス・メトリックを取得する処理のことです。アプリケーションの実行時、DMSはメトリックをメモリーに格納します。これにより、ユーザーはコンソールでメトリックを表示したり、Webブラウザを使用してメトリックを表示できます。
Oracle Application Serverには、dmstool
やAggreSpy
サーブレットなどの、DMSメトリックを表示したり保存するためのランタイム・ツールが用意されています。
例B-1は、dmstool
を使用して出力されるメトリックのセットを示しています。
/dmsDemo [type=n/a] /dmsDemo/BasicBinomial [type=MathSeries] computeSeries.active: 0 threads computeSeries.avg: 21.181818181818183 msecs computeSeries.completed: 11 ops computeSeries.maxActive: 1 threads computeSeries.maxTime: 93 msecs computeSeries.minTime: 0 msecs computeSeries.time: 233 msecs lastComputed.value: 184756 loops.count: 604 ops
この項では、DMSを使用するために理解する必要がある用語について説明します。図B-1は、この章で説明するデモ・アプリケーションのメトリックと例B-1に示すメトリックに対応する、DMSメトリックのセットの構成を示したものです。
この項には、次の項目が含まれています。
DMSメトリックは、開発者、システム管理者およびサポート・アナリストが、システム・パフォーマンスを分析したりシステムの状態を監視するために使用するパフォーマンス情報を追跡します。
DMS Sensorは、パフォーマンス・データを測定します。DMSはSensorによってメトリックのセットを定義および収集します。メトリックには、常にSensorに含まれるものと任意で含まれるものがあります。
DMS PhaseEvent Sensorは、コード内の特定セクションの開始から終了までにかかる時間を測定します。PhaseEvent Sensorを使用すると、あるメソッドまたはコード・ブロックの処理にかかる時間を追跡することができます。
DMSでは、PhaseEvent Sensorの処理にかかる平均時間、最大時間および最小時間など、PhaseEventに関連するオプションのメトリックを計算できます。
表B-1は、PhaseEvent Sensorで使用可能なメトリックを説明したものです。
DMS Event Sensorは、システム・イベントをカウントします。継続時間の短いシステム・イベントや、継続時間よりも発生ポイントが重要なシステム・イベントを追跡する場合は、DMS Event Sensorを使用します。
表B-2は、Event Sensorに関連するメトリックを説明したものです。
メトリック | 説明 |
---|---|
|
プロセス開始以降、イベントが発生した回数を示します。
デフォルト: |
DMS State Sensorには、事前に処理済の値を割り当てます。State Sensorは、Javaプリミティブの値またはJavaオブジェクトのコンテンツを追跡します。integer、double、longおよびobjectなどの型がサポートされています。State Sensorは、システムの状態情報を追跡したり、イベントに関係しないパフォーマンス・メトリックを収集する場合に使用します。たとえば、State Sensorを使用して、キューの長さ、プール・サイズ、バッファ・サイズまたはホスト名などを示すことができます。
表B-3は、State Sensorのメトリックを説明したものです。State Sensorは、デフォルトのメトリックvalue
およびオプションのメトリックをサポートします。minValue
およびmaxValue
のオプション・メトリックは、State Sensorが(integer、doubleおよびlongなどの)数値のJavaプリミティブを表す場合にのみ、State Sensorに適用されます。
DMS Noun(Noun)はパフォーマンス・データを編成します。各Sensorは、関連付けられたメトリックとともに階層構造でNounに付加されます。Nounを使用すると、ファイル・システムのディレクトリ構造と同様の方法で、DMSメトリックを編成できます。たとえば、Nounは、クラス、メソッド、オブジェクト、キュー、接続、アプリケーション、データベースまたはその他のオブジェクトなど、測定の様々な対象を示すことができます。
Nounのタイプには、収集対象となるメトリックのセットを表す名前が使用されます。たとえば、組込みメトリックのNounのタイプoc4j_servlet
は、各J2EEアプリケーション内の各Webモジュールのサーブレットそれぞれについて収集されるメトリックを表します。またNounのタイプJVM
は、サイトで現在実行されている各Javaプロセス(OC4J)に関するメトリックのセットを表します。
Nounのネーミング計画では、階層のルートに「/」を使用し、各NounはルートNounまたは親Nounの下にあるコンテナとして動作します。
DMSロールアップNounは、集計Nounのセットをリクエストするインストルメントを含めるときに、DMSによって生成されるNounです。ロールアップNounには、指定されたNounタイプの子孫Noun内のSensorのセットからのメトリックが含まれます。ロールアップNounには、サマリー情報も含まれます。
この項では、DMSメトリック、SensorおよびNounそれぞれのオブジェクトの関係と属性について説明します。
表B-4は、DMSオブジェクト間の関係を説明したものです。図B-1は、サンプルのメトリックのセットを使用して表B-4に示した関係を図示したものです。
オブジェクト | 含まれる対象 | 属性 |
---|---|---|
Noun |
Sensorまたはその他のNoun |
名前、Nounのタイプ、親 |
Sensor |
メトリック |
Sensorのタイプには、PhaseEvent、EventおよびStateがあります。 |
メトリック |
値 |
名前、単位の指定 |
DMSの名前の定義には、特定のガイドラインが適用されます。このガイドラインに従うことにより、DMSメトリック・レポートの参照ユーザーは、アプリケーション全体およびOracle Application Serverコンポーネント全体のメトリックを簡単に理解することができます。
この項には、次の項目が含まれています。
DMSメトリックの名前は、Sensor名、「.
」およびメトリックで構成されます。たとえば、computeSeries.time
、loops.count
およびlastComputed.value
は有効なDMSメトリックの名前です。
Sensor名は、「.
」や派生を含まない単純な文字列です。たとえば、computeSeries
、loops
およびlastComputed
などです。Sensorのフルネームは、そのSensorが関連付けられたNounの名前、区切り文字、Sensor名で構成されます。たとえば、/dmsDemo/BasicBinomial/computeSeries
、/dmsDemo/BasicBinomial/loops
および/dmsDemo/BasicBinomial/lastComputed
などです。
Noun名は、区切り文字を含まない単純な文字列です。たとえば、BasicBinomial
はNoun名です。Nounのフルネームは、その親のフルネーム、区切り文字、Noun名で構成されます。たとえば、/dmsDemo/BasicBinomial
などです。
DMSの名前はできるかぎり簡潔にしてください。また、NounやSensorの名前を定義する場合は、可能であれば特殊文字(空白、スラッシュ、ピリオド、括弧、カンマ、制御文字など)を使用しないでください。
表B-5は、DMSにおいて置換される、名前内の特殊文字を示します。
文字 | DMSにおける置換文字 |
---|---|
スペース「 」またはピリオド「.」 |
アンダースコア「_」 |
制御文字 |
アンダースコア「_」 |
「<」 |
「(」 |
「>」 |
「)」 |
「&」 |
「^」 |
「”」(二重引用符) |
「‘」(バッククウォート)。二重引用符がバッククウォートに置き換えられます。 |
「’」(一重引用符) |
「‘」(バッククウォート)。一重引用符がバッククウォートに置き換えられます。 |
Nounには、特定のエンティティを識別する名前を付けてください。
Nounのタイプには、収集対象となるメトリックのセットを明確に表す名前を使用する必要があります。たとえば、ServletというNounのタイプは、そのNounで、特定のサーブレットに固有のメトリックを収集することを示します。
Nounのタイプの名前は、他のDMSの名前と区別するために大文字で始めてください。同じタイプのすべてのNounは、同じSensorのセットを持ちます。
次のリストは、DMS Sensorのネーミング規則の概要を示します。
computeSeries
のようになります。
/
」を使用することは避けることをお薦めします。ただし、名前に「/
」を使用することが道理にかなっている場合があります。NounまたはSensor名に「/」を使用した場合、DMSメソッドの文字列でSensorを使用するとき、区切り文字として、パスにまったく存在しない「,」または「_」などを「/」のかわりに使用する必要があります。これによって、「/」は区切り文字ではなく、NounまたはSensor名の一部であることが正しく認識されるようになります。たとえば、次のような名前の子Nounがあるとします。
examples/jsp/num/numguess.jsp
そして次の文字列を使用し検索することができます。
,oc4j,default,WEBs,defaultWebApp,JSPs,example/jsp/num/numguess.jsp,service
ここで、区切り文字は「,」です。
activateInstance
やrunMethod
のようになります。PhaseEventによって、関数、メソッドまたはコード・ブロックを監視する場合は、実行されるタスクを可能なかぎり明確に反映した名前を使用します。
lastComputed、totalMemory
、port
、availableThreads、activeInstances
のようになります。
Javaアプリケーションのパフォーマンス情報を収集するには、DMSインストルメントを既存のアプリケーションに追加するか、DMSインストルメントを含む新しいアプリケーションを作成します。
この章に示すDMSのサンプルは、次のOracle Technology NetworkのWebサイトから入手できます。
http://www.oracle.com/technology/tech/java/oc4j/demos/index.html
DMSのdemo.zip
ファイルには、すぐにデプロイ可能な.earファイルと、ビルド手順付きのソース・コードが含まれています。このデモには、BasicBinomial.java
およびImprovedBinomial.java
の2つのサーブレットが含まれています。
BasicBinomialサーブレットは、DMS APIを使用してDMS 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;
Sensorおよび各Sensorに関連付けるメトリックを編成するには、最初にDMS Nounを定義します。DMS Nounでは、ファイル・システムのディレクトリ構造と同様に、最上位のルートNounの下にツリー階層でSensorが編成されます。
例B-2は、BasicBinomial.java
のNoun.create()
を使用するコードのセクションを示したものです。
例B-2のMathSeries
は、このNounのタイプを示します。Nounのタイプには、収集対象となるメトリックのセットを表す名前を使用します。たとえば、MathSeries
は、二項級数の計算を含むサンプル・アプリケーションについてメトリックを収集することを示します。AggreSpy
では、同じNounタイプのSensorが一緒に表示されます。
Sensorを直接含むNounのNounタイプのみを使用するようにしてください。 Noun dmsDemo
のように、Nounのみ含まれてSensorが直接含まれないNounのNounタイプは、AggreSpy
では、メトリックを含まないメトリック表として表示されます。例B-2は、Noun BasicBinomial
を1つ含んでSensorは含まないdmsDemo
Nounを示しています。このNounに対してNounタイプが指定されない場合、AggreSpy
では、このNounに関連付けられたメトリック表が表示されません。
private Noun binRoot; // Container for Binomial series DMS metrics. Noun base = Noun.create("/dmsDemo"); binRoot = Noun.create(base, "BasicBinomial", "MathSeries");
通常、Nounのタイプは、その祖先Nounまたは子孫Nounとは異なるものにする必要があります。一般的に、これのコード化は容易で、さらには同じタイプのNounが同じレベルにある論理階層を実現します。たとえば、dmsDemo
アプリケーションには、BasicBinomial
サーブレットと、それを拡張した2番目のサーブレットのImprovedBinomial
があります。この場合、インストルメントでは、両方に対してMathSeries
タイプのNounを使用します。このNounは、両方のサーブレットにとって同じ階層レベルとなる/dmsDemo
の下に作成されます。この規則を順守することで、生成されるメトリック表の理解がより容易になります。また、レポート処理時の情報の漏れが最小になります。
コードのセグメントの期間を測定するメトリックを作成するには、次の手順で、PhaseEvent Sensorを定義および使用します。
例B-3は、computeSeries
というPhaseEvent Sensorを宣言して作成するDMSコールを示しています。このコードは、/dmsDemo/BasicBinomial/computeSeries.time
という名前のDMSメトリックを定義します。
PhaseEvent Sensorは、デフォルトのメトリック.time
(PhaseEvent start()
コールからPhaseEvent
stop()
コールまでの合計時間を示す)とともに、オプションのメトリックのセットをサポートします。 PhaseEvent Sensorのオプションのメトリックは、個別に、あるいは完全なメトリックのセットとして得ることができます。表B-1は、PhaseEvent Sensorで使用可能なメトリックを示しています。例B-3の binComp.deriveMetric(Sensor.all)
コールによって、サポートされるすべてのオプションのメトリックが計算されレポートされるようになります。
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を使用するには、アプリケーションで、start()
メソッドをコールしてフェーズの開始を示し、続いてstop()
メソッドをコールしてフェーズの完了を示します。
例B-4は、start()
メソッドおよびstop()
メソッドを使用してdmsDemo/BasicBinomial/computeSeries.time
メトリックを計測する、BasicBinomial.java
のコードのセグメントを示しています。PhaseEvent start()
メソッドから返されるtoken
という名前のlong
値は、対応するPhaseEvent stop()
メソッドに渡す必要があります。この値は、開始時刻を表すタイム・スタンプです。この値をstop()
メソッドに渡すことにより、DMSでPhaseEventの継続時間を計算できます。
注意
PhaseEventが停止したことを確認するには、例B-4に示すように、各PhaseEvent |
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(); }
例B-4は、Phaseが始まるたびに停止される、インストルメントされたコードを示します(finally句にstopメソッドがあるため)。これはPhase Sensorの暴走を防止します。ただし、これによって、例外をスローする時間が必要となり、Phase統計に影響する場合があります。例外処理がPhaseEventに影響を与えるのを避けるには、例B-5に示すように、abort()
メソッドを使用します。
例B-5は、停止されないPhaseは中断されるサンプル・コードを示します。中断のコールが、該当のstartと対応する統計を削除します。そしてこれらの統計は、メトリックの計算に影響しません。
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を次のように定義して使用します。
例B-6は、Event Sensorを定義するDMSコールを示しています。このコードは、カウンタを割り当て、/dmsDemo/BasicBinomial/loops.count
という名前のDMSメトリックを定義します。
private Event binLoop; // Loops needed for Binomial series. . . . binLoop = Event.create(binRoot, "loops", "Iterations to compute series");
アプリケーションでEvent Sensorのoccurred()
メソッドがコールされるたびに、DMSはカウンタを増加させます。例B-7は、/dmsDemo/BasicBinomial/loops.count
メトリックを増加する、Event Sensorのoccurred()
コールを示しています。
binLoop.occurred();
DMSは、State Sensorを使用して状態情報を取得します。State Sensorは、Javaプリミティブの値またはJavaオブジェクトのコンテンツを追跡します。create()
メソッドの3番目の引数として指定しているように、integer、double、longおよびobjectなどの型がサポートされています。JavaプリミティブのState Sensorが不正な型で更新された場合、DMSは指定された値を正しい型に変換しようとします。オブジェクト型のState Sensorの場合、DMSはオブジェクトへの参照を格納し、DMS値をサンプリングする際に、そのオブジェクトに対してtoString()
をコールします。
状態情報を記録するメトリックを作成するには、State Sensorを次のように定義して使用します。
State Sensorは、デフォルトのメトリックvalue
およびオプションのメトリックをサポートします。 minValue
およびmaxValue
のオプション・メトリックは、State Sensorに対し、State Sensorが(integer、double、およびlongなどの)数値のJavaプリミティブを表す場合にのみ定義できます。表B-3は、State Sensorで使用可能なメトリックを示しています。例B-3は、オプションのメトリックを有効にする方法を示しています。
例B-8は、State Sensorを宣言して作成するDMSコールを示しています。このコードは、/dmsDemo/BasicBinomial/lastComputed.value
という名前のDMSメトリックを定義します。
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番目の引数に空の文字列を使用します。または、適切な単位の文字列を使用します(例B-8を参照)。State Sensorは、初期値なしで作成されます。State Sensorが初期化されたかどうかを確認したい場合は、isInitialized()
メソッドを使用します。
オブジェクトへの参照ではなく、オブジェクトの文字列の値をState Sensorが格納するようにするには、値をTRUE
とし、setCopy()
メソッドを使用します。これによって、State Sensorは、メトリック値としてオブジェクトへの参照を使用するのではなく、toString()
をコールした結果をオブジェクトに格納します。
アプリケーションでState Sensorのupdate()
メソッドがコールされると、DMSはState Sensorの値を更新します。例B-9は、/dmsDemo/BasicBinomial/lastComputed.value
メトリックを更新する、State Sensorのupdate()
コールを示しています。
binLast.update(bins[k-1].toString());
Javaアプリケーションに追加するメトリックは、その精度をテストして検証する必要があります。
この項には、次の項目が含まれています。
新しいメトリックを検証してテストするには、dmstool
およびその他の使用可能なDMS監視ツールを使用します。
新しいメトリックについて、次のことを検証してください。
たとえば、プール・サイズを計測するメトリックでは、負の値がレポートされることはありません。
正確性のテストは簡単ではありません。ただし、特定のメトリックを測定する別の方法がある場合は、それを使用してメトリック値を検証します。たとえば、既知の数のリクエストをサーバーへ送信して処理にかかる合計時間を測定する場合、関連するメトリックの適切な値を予測し、それらを実際に監視された値と比較します。また、ログ・ファイルまたはコンソールに書き込まれたレコードを調べれば、Event Sensorのcount
メトリックを検証できます。
メトリックに適用されるタイミングの不正確さをチェックします。タイミングの不正確さは、低分解能のクロックを使用して、継続期間の短い時間隔のメトリックを計測した場合に発生する可能性があります。 たとえば、Windowsシステムでは、デフォルトのJavaのクロックは15ミリ秒ごとに1回早まります。これらのシステムで短時間のイベントについてレポートされるDMSメトリックは、注意深く分析する必要があります。この問題を解決するには、高分解能のクロックの使用を検討してください。
DMSメトリックの使用は、アプリケーションのパフォーマンスに少なからず影響を与えます。メトリックを追加する場合は、次のことに注意してください。
DMSConsole.getSensorWeight()
メソッドが用意されています。このメソッドの中心的な設定は推奨される測定レベルであり、DMSで規定されるものではありません。含めるメトリックを制御するには、実行時、コード内でSensorWeight
の値をテストして、DMSコールを実行するかどうかを判断する必要があります。
DMSメトリックは、DMSレポートへのユーザー・ベースのアクセスをサポートしません。DMSメトリックを定義して使用する場合、DMSメトリックにアクセスできる管理者であれば誰でもそのメトリックを使用できます。DMSメトリックを追加する場合は、顧客の機密情報をメトリックに配置しないよう注意してください。
DMSインストルメントを追加する場合、そのDMSメトリックにアクセスできるユーザーは次のとおりです。
dmstool
コマンドまたはAggreSpy
サーブレットにアクセスできるすべてのユーザーは、メトリックにアクセスできます(デフォルトではこれは管理者に限定されています)。条件付きでインストルメントを制限するには、DMS Sensor Weight機能を使用します。Sensor Weight機能を使用すると、Sensor Weightに特定の値が設定されている場合のみ、負荷のかかるインストルメントを実行するようにアプリケーションを指定できます。この機能を使用すれば、デバッグのみに必要とされるような、負荷のかかるメトリックの収集を制御することができます。
例B-10は、DMSConsole.getSensorWeight()
を使用してSensor Weightの値をテストし、その結果によってメトリックを定義および使用する方法を示しています。
Sensor Weightは、コマンドラインでoracle.dms.sensors
プロパティを使用してグローバルに設定します。このプロパティは、OC4Jスタートアップ・オプションを使用して設定します。このプロパティでサポートされる値には、none
、normal
、heavy
およびall
があります。
/* 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", true, true);
最初の引数にはファイルのパス名、2番目の引数には出力形式を指定します。3番目の引数には、この出力をファイルに追加するか、あるいは出力によってファイルの内容を置き換えるかを指定します。
Sensorの抽象クラスは、PhaseEvent、EventおよびState Sensorを制御するためのメソッドを提供します。reset()
メソッドは、Sensorのメトリックを初期値にリセットします。getResetTime()
メソッドは、Sensorがリセットされたかどうか判断します。destroy()
メソッドは、SensorをDMSから削除して、その基礎となるリソースへの参照を解放します。
DMSでのコーディングの推奨事項を次に示します。
try
ブロック内にない場合は、これをPhaseEventのstart()
を含むtry
ブロックに置きます。また、PhaseEventのstop()
はfinally
ブロックに置きます。または、例B-5のように、finally
ブロックのabort()
メソッドを使用します。init()
メソッドで定義する必要があります。
AggreSpy
では表示されません。
DMSインストルメントを追加する場合、新しいメトリックの要件は慎重に考慮してください。作成したコードが予測したとおりに動作していることを検証するには、十分な数のメトリックを追加することが重要です。
DMSメトリックを追加する場合、次のガイドラインに注意してください。
これらのガイドラインに従って、PhaseEventメトリックを追加すると、次のメリットがあります。
PhaseEventの間、時間間隔を測定するために、DMSはデフォルトでシステム・クロックを使用します。デフォルトのクロックは、ApacheなどのCプロセスではマイクロ秒の単位で、OC4JなどのJavaプロセスではミリ秒の単位で精度をレポートします。パフォーマンス測定の精度向上のために、DMSは、オプションで高分解能クロックをサポートしています。これにより、レポートする時間間隔の単位を選択できます。デフォルトのクロックを使用する場合よりも正確にPhaseEventを測る必要があるとき、またはシステムのデフォルトのクロックが分解能の要件に満たないとき、高分解能クロックを使用できます。
この項には、次の項目が含まれています。
Javaプロセスでは、デフォルトのクロックは、java.lang.System.currentTimeMillis()
を使用します。高分解能クロックを選択すると、クロックが変更されたプロセスで実行されているすべてのアプリケーションに対する、このコールが変更されます。プロセスのスタートアップ・オプションを制御するoracle.dms.clock
およびoracle.dms.clock.units
プロパティを使用し、グローバルにDMSクロックとレポートの単位を設定します。
たとえば、デフォルトの単位で高分解能クロックを使用するには、OC4JのJavaコマンドラインで、次のプロパティを設定します。
-Doracle.dms.clock=highres
表B-6は、oracle.dms.clock
プロパティでサポートされる値を示しています。
表B-7は、oracle.dms.clock.units
プロパティでサポートされる値を示しています。
値 | 説明 |
---|---|
MSECS |
時間がミリ秒に変換され、「msecs」でレポートされることを指定します。 注意: これがデフォルトのクロックのデフォルト値です。 |
NSECS |
時間がナノ秒に変換され、「nsecs」でレポートされることを指定します。 注意: これが高分解能クロックのデフォルト値です。 |
USECS |
時間がマイクロ秒に変換され、「usecs」でレポートされることを指定します。 |
高分解能DMSクロックを使用するときは、次に注意してください。
oracle.dms.clock
およびoracle.dms.clock.units
プロパティを設定する場合、選択した値に大文字と小文字の任意の組合せを使用できます(大小文字の区別は重要ではありません)。たとえば、高分解能クロックを選択する場合、highresでも、HIGHRESでも、HighResでも有効です。
oracle.dms.clock
プロパティが設定されていないときも、デフォルトのクロックを使用します。
oracle.dms.clock.units
プロパティが設定されていないとき、指定したクロックに対しデフォルトの単位を使用します。
表B-8は、サポートされている各プラットフォームに固有の環境変数の設定を示します。高分解能DMSクロックを使用するには、環境変数を適切に設定する必要があります。高分解能クロックは、DMS Cライブラリを使用します。UNIXシステムでは、指定する環境変数のパスにlibdms2.soを含める必要があります。Windowsシステムでは、PATH環境変数にyod.dllを含める必要があります。ナノ秒のクロックが使用不可能な場合には、高分解能のタイミングでミリ秒のクロックを使用します。
Oracle HTTP Serverのパフォーマンスを測定するデフォルトのクロックの分解能はマイクロ秒(usecs)です。Oracle HTTP Serverで実行されているCプロセスの監視には、オプションで、より高分解能のクロックを選択できます。Oracle HTTP Serverで高分解能クロックを使用するには、httpd.confで構成オプションを設定するか、コマンドラインで環境変数を指定する必要があります。
表B-9は、Oracle HTTP ServerのDMSクロックを制御する環境変数を示します。表B-10では、Oracle HTTP ServerのDMSクロックを制御するhttpd.confの構成オプションを示します。コマンドライン・オプションとhttpd.conf構成オプションの両方を設定した場合、コマンドラインよりも構成オプションで設定した値が優先されます。
環境変数 | 説明 |
---|---|
DMS_CLOCK |
DMSタイミングに使用するクロックを指定します。値はoracle.dms.clockと同じように解釈されます。 有効値: DEFAULT、HIGHRES |
DMS_CLOCK_UNITS |
DMSタイミング値をレポートする単位を指定します。値はoracle.dms.clock.unitsと同じように解釈されます。 デフォルト値: USECS |
たとえば、高分解能クロックを使用して、OC4Jで実行されているJavaプロセスとOracle HTTP Serverで実行されているmod_oc4jの時間を表示するために同じ単位を使用する場合、次のパラメータおよび値が含まれるよう、Oracle HTTP Serverのhttpd.confファイルを更新します。
DmsClock=HIGHRES DmsClockUnits=MSECS
また、OC4Jプロセスのスタートアップ・オプションとして次の値も含めます。
-Doracle.dms.clock=HIGHRES -Doracle.dms.clock.units=MSECS
これらのオプションを使用して、DMSは、監視するすべてのOracle HTTP ServerプロセスおよびJava OC4Jプロセスに対して高分解能クロックを使用します。そして、DMSはミリ秒(msecs)単位で値をレポートします。
Oracle Application Server 10gリリース3(10.1.3.1.0)には、メトリックの集計を指定できるDMSロールアップ機能が用意されています。このロールアップ機能を使用することで、DMSのインストルメント時にメトリックの集計を指定できます。ロールアップの適用は、特定のNounタイプの子孫に対して指定します。ロールアップは、直接の子孫のみに適用することも、すべての子孫に適用することもできます。例B-11は、図B-2に示すDMSツリーを生成するコードを示しています。myContainer
タイプの各Nounには、percentageFull
、close
およびopen
Sensorが含まれます(図B-3を参照)。
注意 例B-11のコードでは、「Nounのタイプの選択」に説明されている推奨事項に違反するNounのツリー階層が生成されます。この例では、一部のNounが同じタイプの子孫および祖先Nounを持つことが道理にかなっています。この項で説明するロールアップ機能では、他の方法では失われる可能性があるデータを収集できます。 |
// 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);図B-2 ツリー内にメトリックがあるDMSコンテナ階層
図B-2は、子孫コンテナを持つツリーを示しています。Bedrooms BR1
とBR2
の下にあるC1
およびC2
Nounは、myContainer
タイプです(myContainer
メトリックの説明は図B-3を参照)。
DMSでは、ロールアップ機能を使用して、子孫Nounのサマリーを集計できます。たとえば、Bedrooms
Nounに対して、例B-11に示されているロールアップ・コールを追加できます。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);
ロールアップ・メトリックには、その内容を集計するサマリー情報があります。表B-11に、各Sensorのタイプで使用できる派生のロールアップ・メトリックを示します。
例B-12に、/Home/Containers/Closets
下のmyContainer
ロールアップNounに対して作成されたサンプル・メトリックを示します。
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
メトリックと類似していることに注意してください。ロールアップ・メトリックの場合、主に次のような違いがあります。
descendent
、rolled
およびrefresh
メトリックがあります(詳細は表B-11を参照)。
percentageFull
Stateには、value
メトリックではなく、sum
およびavg
メトリックがあります。各メトリックの名前は、その内容を示しています。
close
Event
には、count
メトリックではなく、sum
およびavg
メトリックが含まれます。各メトリックの名前は、その内容を示しています。
open
PhaseEvent
には、maxActive
メトリックは含まれません。このコンテキストでは意味を持たないためです。
|
![]() Copyright © 2001, 2008, Oracle. All Rights Reserved. |
|