![]() ![]() ![]() ![]() ![]() ![]() ![]() |
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アプリケーション実行時の管理』の実行中のアプリケーションの監視に関する項を参照してください。
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で、これらのオプションを説明します。
これらのオプションの詳細は、『Oracle Tuxedoアプリケーション実行時の管理』および『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』の「UBBCONFIG(5)」、「TM_MIB(5)」および「tuxenv(5)」を参照してください。
|
||
このオプションを設定するには、tuxenv(5)を使用します。詳細は、『Oracle Tuxedoアプリケーション実行時の管理』、および『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のtuxenv(5)に関する項を参照してください。
|
||
このオプションの設定は、UBBCONFIGファイルのRESOURCESセクションで行います。詳細は、『Oracle Tuxedoアプリケーション実行時の管理』、および『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』に記載された「UBBCONFIG(5)」の「RESOURCES」セクション内にある「OPTION」を参照してください。
|
||
NO_XAオプションの詳細は、『Oracle Tuxedoアプリケーション実行時の管理』、および『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』の「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アプリケーション実行時の管理』の実行中のシステムの監視に関する項を参照してください。
トラフィックの量がリソース容量の上限に近くなると、システムにボトルネックが生じる可能性があります。サービス・トラフィックを測定するには、実装コードでグローバル・カウンタを使用します。
たとえば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でシステム情報を収集しボトルネックを検出するには、パフォーマンス・モニターを使用します。「スタート」メニューの「設定」をポイントして「コントロール・パネル」をクリックします。次に、「管理ツール」の「パフォーマンス」をクリックします。
![]() ![]() ![]() |