|
|
Oracle Tuxedo アプリケーションのモニタリングの詳細については、『Oracle Tuxedo アプリケーション実行時の管理』の「Oracle Tuxedo アプリケーションのモニタ」を参照してください。
| 注意 : | Oracle Tuxedo CORBA Java クライアントと Oracle Tuxedo CORBA Java クライアント ORB は Tuxedo 8.1 で非推奨になり、今後はサポートされなくなりました。すべての Oracle Tuxedo CORBA Java クライアントおよび Oracle Tuxedo CORBA Java クライアント ORB のテキスト リファレンスとコード サンプルは、サード パーティ製の Java ORB ライブラリを実装または実行する際の参考や、プログラマの参照用としてのみ使用してください。 |
| 注意 : | サード パーティの CORBA Java ORB のテクニカル サポートは、各ベンダによって提供されます。Oracle Tuxedo では、サード パーティの CORBA Java ORB に関する技術的なサポートやマニュアルは提供していません。 |
次の領域で正しい判断を行うことで、Oracle Tuxedo アプリケーションの機能が向上します。
| 注意 : | 複数サーバ、単一キュー (MSSQ) セットは、Oracle Tuxedo CORBA サーバではサポートされていません。 |
表 4-1 では、Oracle Tuxedo サーバで MSSQ セットを使用する場合について説明します。
次の 2 つの例で、MSSQ セットの使用が適している場合と適さない場合がある理由を示します。
Oracle Tuxedo では、システム全体に対し、ロード バランシングのアルゴリズムを使用するかどうかを制御できます。ロード バランシングを使用すると、ロード ファクタがシステム内の各サービスに適用され、各サーバの負荷の合計を追跡できます。各サービス要求は、負荷が最も少ない適切なサーバに送信されます。
| 注意 : | Oracle Tuxedo CORBA システムでは、システム制御のロード バランシングは自動的に有効化されます。LDBAL=N を指定しても、ロード バランシングを無効化することはできません。 |
SERVICES セクションにあるロード ファクタの割り当て方法を決定するには、アプリケーションを継続的に動作させて、各サービスの実行にかかる平均時間を計算します。算出した平均時間を必要とするサービスの場合は、LOAD 値に 50 (LOAD=50) を割り当てます。算出した平均値よりも長い時間がかかるサービスの場合は、LOAD>50 とします。算出した平均値より短い時間で済むサービスの場合は、LOAD<50 とします。
実行された各サービスにには、ロード ファクタ (LOAD) が割り当てられます。これにより、各サーバが実行したサービスの負荷の合計が追跡されます。各サービス要求は、負荷の合計が最も低いサーバにルーティングされます。ルーティング先のサーバの負荷合計は、要求されたサービスの LOAD ファクタ分だけ増加します。
また、インタフェースにも LOAD ファクタを適用することができます。LOAD ファクタの詳細については、『Oracle Tuxedo アプリケーション実行時の管理』の「コンフィグレーション ファイルの作成」を参照してください。
複製されたサーバ プロセスおよびグループを Oracle Tuxedo ドメイン内でコンフィグレーションするには、次の手順に従います。
UBBCONFIG ファイルを編集します。GROUPS セクションで、コンフィグレーションするグループの名前を指定します。SERVERS セクションでは、複製するサーバ プロセスについて、表 4-2 に記載のパラメータを指定します。
MIN パラメータと MAX パラメータは、所定のサーバ アプリケーションが所定のインタフェース上で要求を並行処理できるレベルを決定します。実行時には、システム管理者はリソース上のボトルネックを検証し、必要であればさらなるサーバ プロセスを開始して、アプリケーションをスケーリングできます。詳細については、『Oracle Tuxedo アプリケーション実行時の管理』の「Oracle Tuxedo アプリケーションのモニタ」を参照してください。
| 注意 : | MAX パラメータは、インスタンスの最大数を制御します。ただし、Oracle Tuxedo はインスタンスを自動的に作成することはありません。システムは、指定された MIN 数値分のインスタンスを自動的に開始します。MIN と MAX の中間の場合は、システム管理者が手動で新規インスタンスを作成する必要があります。いったん MAX に到達すると、tmboot、tmadmin、または TMIB API によってエラーが返されます。 |
マルチスレッド サーバの詳細については、「マルチスレッド サーバの使用」を参照してください。
Oracle XA データベース ソフトウェアと相互運用する場合に、マルチスレッド サーバによるスレッドの使用を可能にするには、コード リスト 4-1 に示すように、UBBCONFIG ファイルの GROUPS セクションで OPENINFO パラメータに Threads=true を追加する必要があります。詳細については、Oracle XA のオンライン マニュアルを参照してください。
OPENINFO="ORACLE_XA:Oracle_XA+Acc=P/scott/tiger+SesTm=100+LogDir=.+MaxCur=5+Threads=true"
マルチスレッド CORBA サーバのコンフィグレーションには、次のパラメータを使用します。これらのパラメータは、UBBCONFIG ファイルで設定します。
これらのパラメータの設定方法については、次のトピックを参照してください。
PRIO パラメータを使用して、Oracle Tuxedo インタフェースに優先順位を割り当てることにより、アプリケーション内のデータ フローを有効に制御できます。Oracle Tuxedo システムで動作する CORBA アプリケーションの場合、PRIO パラメータは、アプリケーションの UBBCONFIG ファイルの INTERFACES セクションで名前を指定した各インタフェースについて指定できます。
たとえば、サーバ 1 が、インタフェース A、B、および C を提供するとします。インタフェース A および B の優先順位は 50、インタフェース C の優先順位は 70 です。インタフェース C に対する要求は、A または B に対する要求より常に先にキューから取り出されます。A および B に対する要求は、互いに等しくキューから取り出されます。システムは、10 回に 1 回の割合で先入れ先出し (FIFO) 順序で要求をキューから取り出し、メッセージがキューで無制限に待機しないようにします。
tpsprio() 呼び出しを使用すると、優先順位を動的に変更できます。ただし、選ばれたクライアントだけがインタフェースの優先順位を高く設定できるようにします。サーバがインタフェース要求を行うシステムでは、サーバサイドから tpsprio() を呼び出し、インタフェース呼び出しの優先順位を上げることができます。これによりユーザは、必要なインタフェース要求を待たずに済みます。
PRIO パラメータは、慎重に使用してください。キューのメッセージの順序 (たとえば A、B、C) によっては、10 回に 1 回の割合でしか、一部 (A および B など) がキューから取り出されません。つまり、サービスのパフォーマンスが低下し、ターンアラウンド タイムが遅くなる可能性があります。
優先順位を割り当てることで、最も重要な要求の処理はより効率的に行い、重要性の低い要求の処理は遅らせて行うことができます。また、特定のユーザまたは特定の状況に対して優先順位を付けることも可能です。
複数のサービスをサーバの実行可能ファイルにパッケージ化する最も簡単な方法は、まったくパッケージ化しないことです。しかし、サービスをパッケージ化しないと、サーバの実行可能ファイル、メッセージ キューおよびセマフォの数が許容範囲を超える原因となります。サービスをまったくバンドルしない (まとめない) 場合と細かくバンドルする (まとめる) 場合では、それぞれ長所と短所があります。
bankapp アプリケーションでは、WITHDRAW、DEPOSIT、および INQUIRY の各サービスはすべて、窓口オペレーションです。サービスの管理は、簡略化されます。
Oracle Tuxedo のリリース 8.0 から、パフォーマンス オプションが追加されました。これらのオプションにより、Oracle Tuxedo のインフラストラクチャで特定の機能を無効化できます。無効化するのは、CORBA または ATMI アプリケーションで必要でない機能のみとしてください。表 4-3 で、これらのオプションを説明します。
UBBCONFIG(5)」、「TM_MIB(5)」、および「tuxenv(5)」を参照してください。
|
||
tuxenv(5) を使用します。詳細については、『Oracle Tuxedo アプリケーション実行時の管理』および『Oracle Tuxedo のファイル形式とデータ記述方法』の「tuxenv(5)」を参照してください。
|
||
UBBCONFIG ファイルの RESOURCES セクションで行います。詳細については、『Oracle Tuxedo アプリケーション実行時の管理』、および『Oracle Tuxedo のファイル形式とデータ記述方法』に記載された UBBCONFIG(5) の RESOURCES セクション内にある OPTION を参照してください。
|
||
NO_XA オプションの詳細については、『Oracle Tuxedo アプリケーション実行時の管理』、および『Oracle Tuxedo のファイル形式とデータ記述方法』の「UBBCONFIG(5)」と「TM_MIB(5)」を参照してください。
|
これらのアプリケーション パラメータを設定することにより、システム効率を向上できます。
MAXDISPATCHTHREADS パラメータは、各サーバ プロセスで生成される、同時に実行できるディスパッチ スレッドの最大数を決定します。このパラメータを指定する際には、次の事項を考慮してください。
MAXDISPATCHTHREADS の値によって、受信する要求を格納するために拡大できる最大サイズが決定されます。MAXDISPATCHTHREADS のデフォルト値は 1 です。1 より大きい値を指定した場合、特別なディスパッチ スレッドが作成および使用されます。このディスパッチャ スレッドは、スレッド プールの最大サイズを決定するスレッド数には、含まれていません。MAXDISPATCHTHREADS パラメータの値に 1 を指定すると、サーバ アプリケーションがシングル スレッド サーバとしてコンフィグレーションされることを示します。1 より大きい値を指定すると、サーバ アプリケーションがマルチスレッド サーバとしてコンフィグレーションされることを示します。MAXDISPATCHTHREADS パラメータに指定する値は、MINDISPATCHTHREADS パラメータに指定する値を下回っていてはいけません。 MAXDISPATCHTHREADS は、その制限値より少ない、アプリケーションが必要とするアプリケーション管理スレッドの数を差し引いた値にします。
MAXDISPATCHTHREADS パラメータの値は、ほかのパラメータにも影響を与えます。たとえば、MAXACCESSORS パラメータは Oracle Tuxedo システムへの同時アクセス数を制御します、各スレッドは、1 つのアクセサとしてカウントされます。マルチスレッド サーバのアプリケーションの場合、各サーバの実行がコンフィグレーションされているシステム管理のスレッドの数を考慮しておく必要があります。システム管理のスレッドとは、アプリケーションで開始され管理されるスレッドに対して、Oracle Tuxedo ソフトウェアで開始され管理されるスレッドです。内部では Oracle Tuxedo が、利用可能なシステム管理のスレッドのプールを管理しています。クライアント要求が受信されると、スレッド プールから利用可能なシステム管理のスレッドがその要求を実行するように、スケジューリングされています。要求が完了すると、システム管理のスレッドは利用可能なスレッドのプールに返されます。
たとえば、システム内に 4 つのマルチスレッド サーバがあり、各サーバが 50 個のシステム管理のスレッドを実行するようにコンフィグレーションされている場合、これらのサーバにおけるアクセサ要件は、次のように計算される、アクセサ数の合計となります。
サーバが最初にブートされたときに開始されるサーバ ディスパッチ スレッドの数を指定するには、MINDISPATCHTHREADS パラメータを使用します。このパラメータを指定する際には、次の事項を考慮してください。
MAXACCESSERS、MAXOBJECTS、MAXSERVERS、MAXINTERFACES、および MAXSERVICES の各パラメータを使用すると、セマフォおよび共有メモリのコストが増大するため、システムの要求を満たす最低限の値を選択してください。また、システムに同時にアクセスできるクライアント数を設定できるようにしておく必要もあります。これらのパラメータには、デフォルトで IPC リソースが適度に割り当てられています。しかし、アプリケーションにとって必要最低限の値を設定するのが賢明です。
マルチスレッド サーバの場合、各サーバの実行がコンフィグレーションされているスレッドの数を考慮しておく必要があります。MAXACCESSERS パラメータは、Oracle Tuxedo システムの同時アクセサの最大数を設定します。アクセサには、ネイティブおよびリモートのクライアント、サーバ、および管理プロセスが含まれます。MAXACCESSERS パラメータの設定の詳細については、「MAXDISPATCHTHREADS」を参照してください。
システム内のクライアント数に、それらのクライアントがトランザクションをコミットする回数のパーセンテージを掛けた値が 100 に近い場合には、MAXGTT パラメータの値を大きくする必要があります。MAXGTT の値を大きくした場合には、それに応じて、各マシンの TLOGSIZE の値も大きくする必要があります。分散トランザクションを使用しないアプリケーションの場合は、MAXGTT を 0 に設定します。
アプリケーションで受け付けられるバッファのタイプおよびサブタイプの数はそれぞれ、MAXBUFTYPE パラメータおよび MAXBUFSTYPE パラメータで制限できます。MAXBUFTYPE の現在のデフォルト値は 16 です。ユーザ定義のバッファ タイプが多数指定されていない限り、MAXBUFTYPE は省略できます。しかし、何種類もの VIEW サブタイプを使用する予定がある場合は、MAXBUFSTYPE の設定を、現在のデフォルト値である 32 より増やしておきます。
システムが、使用率が高いなどの理由で処理の遅いプロセッサで稼動している場合は、タイミング パラメータである SANITYCAN、BLOCKTIME、およびトランザクションのタイムアウト値を増やします。ネットワークの動作が遅い場合は、BLOCKTIME、BBLQUERY および DBBLWAIT パラメータの値を増やします。
表 4-4 では、アプリケーションのチューニングに使用できるシステム パラメータを説明します。
IPC 要件は、さまざまなシステム パラメータの値で決まります。tmboot -c コマンドを使用すると、コンフィグレーションの IPC 要件をテストできます。次のパラメータの値は、アプリケーションの IPC 要件に影響をもたらします。
表 4-5 では、アプリケーションで必要とされる IPC に影響を与えるシステム パラメータについて説明します。
Oracle Tuxedo アプリケーションのモニタとトラフィック測定の詳細については、『Oracle Tuxedo アプリケーション実行時の管理』の「Oracle Tuxedo アプリケーションのモニタ」を参照してください。
トラフィックの量がリソース容量の上限に近くなると、システムにボトルネックが生じる可能性があります。サービス トラフィックを測定するには、実装コードでグローバル カウンタを使用します。
たとえば Tuxedo アプリケーションでは、ブート時に tpsvrinit() が呼び出されると、グローバル カウンタを初期化して、開始時間を記録できます。以降、特定のサービスが呼び出されるたびにカウンタ値は増加します。tpsvrdone() 関数を呼び出してサーバを停止すると、最終カウンタ値と終了時間が記録されます。このメカニズムにより、一定期間に特定サービスのビジー状態がどの程度であるかを判断できます。
| 注意 : | CORBA C++ アプリケーションの場合は、Server::initialize() オペレーションと Server::release() オペレーションを使用します。 |
Oracle Tuxedo では、データ フローのパターンが原因でボトルネックが生じます。ボトルネックを検出する最も早い方法は、クライアント側から関連するサービスに要する時間を測定することです。
クライアント 1 では、画面の出力に 4 秒必要であるとします。time(2) を呼び出すと、サービス A に対する tpcall が動作を 3.7 秒遅らせていることがわかります。サービス A を開始点と終了点でモニタすると、0.5 秒かかっています。これは、キューがいっぱいであることを示唆しています。この判断は、pq コマンドを使用して行われます。
一方、サービス A の実行に 3.2 秒かかるとします。サービス A の個々の部分はまとめて測定できます。サービス A がサービス B に対して tpcall を発行し、この動作に 2.8 秒かかっていることも考えられます。この場合、キュー時間またはメッセージ送信ブロッキング時間を分離できます。適切な時間を識別すると、アプリケーションはトラフィックを処理できるように再度チューニングされます。
time(2) を使用すると、次の項目の所要時間を測定できます。
UNIX システムの sar(1) コマンドを使用すると、システムのボトルネックの検出に役立つパフォーマンスについての情報が表示されます。sar(1) は、次の目的に使用できます。
表 4-6 は、sar(1) コマンドのオプションの説明です。
| 注意 : | UNIX プラットフォームの中には、sar(1) コマンドの代わりに別のコマンドが用意されているものもあります。たとえば、BSD には iostat(1) コマンド、Sun Microsystems, Inc. には perfmeter(1) が用意されています。 |
Windows でシステム情報を収集しボトルネックを検出するには、パフォーマンス モニタを使用します。[スタート] メニューの [設定] をポイントして [コントロール パネル] をクリックします。次に、[管理ツール] の [パフォーマンス] をクリックします。
  
|