CORBAアプリケーションのスケーリング、分散およびチューニング

     前  次    新規ウィンドウで目次を開く  新規ウィンドウで索引を開く  PDFとして表示 - 新規ウィンドウ  Adobe Readerを入手 - 新規ウィンドウ
コンテンツはここから始まります

CORBAアプリケーションのチューニング

このトピックには次の項が含まれます:

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 ATMIサーバーのみ)

注: 複数サーバー、単一キュー(MSSQ)セットは、Oracle Tuxedo CORBAサーバーではサポートされていません。

表4-1では、Oracle TuxedoサーバーでMSSQセットを使用する場合について説明します。

表4-1 MSSQセットを使用する場合と、使用しない場合
MSSQセットを使用する場合
MSSQセットを使用しない場合
複数のサーバーが存在するが多くはない場合。
多数のサーバーがある場合。(妥協策は、多数のMSSQセットを使用することです。)
バッファ・サイズが適度な大きさである場合。
バッファ・サイズが1つのキューでいっぱいになる場合。
各サーバーが同じサービスのセットを提供する場合。
各サーバーに対するサービスが異なる場合。
適度なサイズのメッセージが含まれている場合。
キューがいっぱいになるほど長いメッセージがサービスに渡される場合。この場合、非ブロッキング送信が失敗するか、またはブロッキング送信がブロックされます。
サービスのターンアラウンド・タイムが最適であり、一貫性があることが重要視される場合。
サービスのターンアラウンド・タイムが最適であり、一貫性があることが重要視されない場合。

次の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ドメイン内で構成するには、次の手順に従います。

  1. テキスト・エディタを使用して、アプリケーションのUBBCONFIGファイルを編集します。
  2. GROUPSセクションで、構成するグループの名前を指定します。
  3. SERVERSセクションでは、レプリケートするサーバー・プロセスについて、表4-2に記載のパラメータを指定します。
  4. 表4-2 SERVERSセクションで指定されるパラメータ
    パラメータ
    説明
    サーバー・アプリケーション名
    アプリケーション・サーバーを含む実行可能ファイルの名前を指定します。
    GROUP
    サーバー・プロセスが所属するグループの名前を指定します。複数のグループに関係するサーバー・プロセスをレプリケートする場合は、各グループに1つずつサーバー・プロセスを指定します。
    SRVID
    数値による識別子を指定し、サーバー・プロセスにユニークなIDを付与します。
    MIN
    アプリケーションの起動時に開始するサーバー・プロセスのインスタンス数を指定します。
    MAX
    同時に実行できるサーバー・プロセスの最大数を指定します。

    MINおよびMAXパラメータは、指定のサーバー・アプリケーションが指定のインタフェースでリクエストをどの程度まで並列処理できるかを指定します。実行時には、必要に応じて、システム管理者がリソースのボトルネックを調べて、新しいサーバー・プロセスを起動することができます(アプリケーションのスケーリングも行われます)。詳細は、『Oracle Tuxedoアプリケーション実行時の管理』の実行中のアプリケーションのモニタリングに関する項を参照してください。

    MAXパラメータは、インスタンスの最大数を制御します。ただし、Oracle Tuxedoはインスタンスを自動的に作成することはありません。システムは、指定されたMIN数値分のインスタンスを自動的に開始します。MINMAXの間の場合は、システム管理者が手動で新規インスタンスを作成する必要があります。MAXに到達すると、tmboottmadmin、またはTMIB APIによってエラーが返されます。

 


マルチスレッド・サーバーの構成

このトピックには次の項が含まれます:

マルチスレッド・サーバーの詳細は、「マルチスレッド・サーバーの使用」を参照してください。

データベースの相互運用のためのOPENINFOパラメータの設定

Oracle XAデータベース・ソフトウェアと相互運用する場合にマルチスレッド・サーバーによるスレッドの使用を有効化するには、リスト4-1に示されているように、UBBCONFIGファイルのGROUPSセクションにあるOPENINFOパラメータにThreads=trueを追加する必要があります。詳細は、Oracle XAオンライン・ドキュメントを参照してください。

リスト4-1 OPENINFOパラメータへのThreads=trueの追加
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パラメータの特性

PRIOパラメータは、慎重に使用してください。キューのメッセージの順序(たとえばA、B、C)によっては、10回に1回の割合でしか、一部(AおよびBなど)がキューから取り出されません。つまり、サービスのパフォーマンスが低下し、ターンアラウンド・タイムが遅くなる可能性があります。

PRIOパラメータの特性は、次のとおりです。

優先度を割り当てることで、最も重要なリクエストの処理はより効率的に行い、重要性の低いリクエストの処理は遅らせて行うことができます。また、特定のユーザーまたは特定の状況に対して優先度を付けることも可能です。

 


サーバーへのサービスのバンドル(Oracle Tuxedo ATMIサーバーのみ)

このトピックには次の項が含まれます:

サービスのバンドルについて

複数のサービスをサーバーの実行可能ファイルにパッケージ化する最も簡単な方法は、まったくパッケージ化しないことです。しかし、サービスをパッケージ化しないと、サーバーの実行可能ファイル、メッセージ・キューおよびセマフォの数が許容範囲を超える原因となります。サービスをまったくバンドルしない(まとめない)場合と細かくバンドルする(まとめる)場合では、それぞれ長所と短所があります。

サービスのバンドルが必要な場合

サービスをバンドルする理由は、次のとおりです。

 


パフォーマンスのオプション

Oracle Tuxedoのリリース8.0から、パフォーマンス・オプションが追加されました。これらのオプションにより、Oracle Tuxedoのインフラストラクチャで特定の機能を無効化できます。無効化するのは、CORBAまたはATMIアプリケーションで必要でない機能のみとしてください。表4-3で、これらのオプションを説明します。

表4-3 パフォーマンス・オプション
オプション
説明
設定方法
サービスおよびインタフェースのキャッシュ・オプション(SICACHEENTRIESMAXおよびTMSICACHEENTRIESMAX)
このオプションにより、サービスおよびインタフェースのエントリをキャッシングし、掲示板をロックすることなくサービスまたはインタフェースのキャッシングしたコピーを使用できます。
これらのオプションの詳細は、『Oracle Tuxedoアプリケーション実行時の管理』および『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』の「UBBCONFIG(5)」、「TM_MIB(5)」および「tuxenv(5)」を参照してください。
スレッドの無効化(TMNOTHREADS)
マルチスレッド処理を無効化するには、このオプションを「yes」に設定します。このスレッドを使用しないアプリケーションで、これらを無効にすると、パフォーマンスが著しく向上します。
このオプションを設定するには、tuxenv(5)を使用します。詳細は、『Oracle Tuxedoアプリケーション実行時の管理』、および『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のtuxenv(5)に関する項を参照してください。
認可と監査の無効化(オプション{[NO_AA]})
このオプションを設定すると、アプリケーションごとに監査および認可の機能を無効化できます。
このオプションの設定は、UBBCONFIGファイルのRESOURCESセクションで行います。詳細は、『Oracle Tuxedoアプリケーション実行時の管理』、および『Oracle Tuxedoファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』に記載された「UBBCONFIG(5)」の「RESOURCES」セクション内にある「OPTION」を参照してください。
XAトランザクションの無効化(NO_XA)
このオプションを設定すると、XAトランザクションを無効化できます。

 


アプリケーション・パラメータによる効率の向上

このトピックには次の項が含まれます:

これらのアプリケーション・パラメータを設定することにより、システム効率を向上できます。

MAXDISPATCHTHREADS

MAXDISPATCHTHREADSパラメータは、各サーバー・プロセスで生成される、同時に実行できるディスパッチ・スレッドの最大数を決定します。このパラメータを指定する際には、次の事項を考慮してください。

MAXDISPATCHTHREADSパラメータの値は、他のパラメータにも影響を与えます。たとえば、MAXACCESSORSパラメータはOracle Tuxedoシステムへの同時アクセス数を制御し、各スレッドは1つのアクセッサとしてカウントされます。マルチスレッド・サーバーのアプリケーションの場合、各サーバーの実行が構成されているシステム管理のスレッドの数を考慮しておく必要があります。システム管理のスレッドとは、アプリケーションで開始され管理されるスレッドとは対照的に、Oracle Tuxedoソフトウェアで開始され管理されるスレッドです。内部ではOracle Tuxedoが、利用可能なシステム管理のスレッドのプールを管理しています。クライアント・リクエストが受信されると、スレッド・プールから利用可能なシステム管理のスレッドがそのリクエストを実行するように、スケジューリングされています。リクエストが完了すると、システム管理のスレッドは利用可能なスレッドのプールに返されます。

たとえば、システム内に4つのマルチスレッド・サーバーがあり、各サーバーが50個のシステム管理のスレッドを実行するように構成されている場合、これらのサーバーにおけるアクセサ要件は、次のように計算される、アクセサ数の合計となります。

50 + 50 + 50 + 50 = 200アクセサ

MINDISPATCHTHREADS

サーバーが最初にブートされたときに開始されるサーバー・ディスパッチ・スレッドの数を指定するには、MINDISPATCHTHREADSパラメータを使用します。このパラメータを指定する際には、次の事項を考慮してください。

MAXACCESSERS、MAXOBJECTS、MAXSERVERS、MAXINTERFACES、およびMAXSERVICESパラメータの設定

MAXACCESSERSMAXOBJECTSMAXSERVERSMAXINTERFACES、およびMAXSERVICESの各パラメータを使用すると、セマフォおよび共有メモリーのコストが増大するため、システムの要求を満たす最低限の値を選択してください。また、システムに同時にアクセスできるクライアント数を設定できるようにしておく必要もあります。これらのパラメータには、デフォルトでIPCリソースが適度に割り当てられています。しかし、アプリケーションにとって必要最低限の値を設定するのが賢明です。

マルチスレッド・サーバーの場合、各サーバーの実行が構成されているスレッドの数を考慮しておく必要があります。MAXACCESSERSパラメータは、Oracle Tuxedoシステムの同時アクセッサの最大数を設定します。アクセッサには、ネイティブおよびリモートのクライアント、サーバー、および管理プロセスが含まれます。MAXACCESSERSパラメータの設定の詳細は、「MAXDISPATCHTHREADS」を参照してください。

MAXGTT、MAXBUFTYPE、およびMAXBUFSTYPEパラメータの設定

システム内のクライアント数と、それらのクライアントがトランザクションをコミットする時間の割合を乗算した積が100に近い場合は、MAXGTTパラメータの値を増やす必要があります。コミットの速度に応じて、これには大量のクライアントが必要になる場合があります。MAXGTTを増やす場合は、各マシンのTLOGSIZEもそれに応じて増やす必要があります。分散トランザクションを使用しないアプリケーションでは、MAXGTT0に設定する必要があります。

アプリケーションで受け付けられるバッファのタイプおよびサブタイプの数はそれぞれ、MAXBUFTYPEパラメータおよびMAXBUFSTYPEパラメータで制限できます。MAXBUFTYPEの現在のデフォルト値は16です。ユーザー定義のバッファ・タイプが多数指定されていないかぎり、MAXBUFTYPEは省略できます。しかし、何種類ものVIEWサブタイプを使用する予定がある場合は、MAXBUFSTYPEの設定を、現在のデフォルト値である32より増やしておきます。

SANITYSCAN、BLOCKTIME、BBLQUERY、およびDBBLWAITパラメータの設定

システムが遅いプロセッサで稼働している場合(使用率が高い場合など)、タイミング・パラメータであるSANITYCANBLOCKTIME、および個々のトランザクションのタイムアウト値を増やします。ネットワークが遅い場合は、BLOCKTIMEBBLQUERYおよびDBBLWAITパラメータの値を増やします。

 


アプリケーション・パラメータの設定

表4-4では、アプリケーションのチューニングに使用できるシステム・パラメータを説明します。

表4-4 アプリケーションのチューニングに使用するシステム・パラメータ
パラメータ
アクション
MAXACCESSERSMAXOBJECTSMAXSERVERSMAXINTERFACES、およびMAXSERVICES
必要最低限の値を設定します(IPCコストの関係上)。
クライアントを追加できるように設定します。
MAXGTTMAXBUFTYPE、およびMAXBUFSTYPE
MAXGTTの値を増やして、多数のクライアントを許容します。トランザクション処理を行わないアプリケーションでは、MAXGTT0に設定します。
ユーザー定義のバッファ型を8つ以上作成する場合にかぎり、MAXBUFTYPEを使用します。
何種類ものVIEWサブタイプを使用する場合は、MAXBUFSTYPEの値を増やします。
BLOCKTIMETRANTIME、およびSANITYSCAN
システムの動作が遅い場合は値を増やします。
BLOCKTIMETRANTIMEBBLQUERY、およびDBBLWAIT
ネットワークの動作が遅い場合は値を増やします。

 


IPC要件の決定

IPC要件は、様々なシステム・パラメータの値で決まります。tmboot -cコマンドを使用すると、構成のIPC要件をテストできます。次のパラメータの値は、アプリケーションのIPC要件に影響をもたらします。

表4-5では、アプリケーションで必要とされるIPCに影響を与えるシステム・パラメータについて説明します。

表4-5 IPCパラメータのチューニング
パラメータ
アクション
MAXACCESSERS
セマフォの数を指定します。
メッセージ・キューの数は、MAXACCESSERS +応答キューを持つサーバー数(MSSQセットのサーバー数+ MSSQセット数)とほぼ同じです。
MAXSERVERSMAXSERVICES、およびMAXGTT
MAXSERVERSMAXSERVICESMAXGTTの3つ、およびROUTINGGROUPNETWORKの3つのセクションの全体のサイズは共有メモリーのサイズに影響し、これらのパラメータの相関関係を計算式に表そうとすると複雑になります。かわりに、単純にtmboot -cまたはtmloadcf -cを実行すると、アプリケーションで最低限必要なIPCのリソース要件を計算することができます。
キューに関連するカーネル・パラメータ
クライアントとサーバー間のバッファ・トラフィックのフローを管理するためにチューニングします。キューの最大サイズ(バイト単位)は、アプリケーションで最も大きいメッセージを処理でき、通常は75 - 85パーセントが使用中になる大きさに設定します。それよりパーセンテージを低くすると、無駄が生じます。それより大きくすると、ブロックへのメッセージ送信頻度が高くなりすぎます。
アプリケーションが送信するメッセージに対して最大のバッファを処理できるように最大サイズを設定します。
キューの最大長(キューに同時にとどまることができる最大メッセージ数)は、アプリケーションにおける操作に適した大きさに設定する必要があります。
キューの平均使用率と平均長を測定するには、アプリケーションをシミュレートするか、または実行します。これは、アプリケーションの実行前にチューニング可能なパラメータを予測し、アプリケーションの実行後にパフォーマンス分析に基づいてそのパラメータを調整するという、試行錯誤のプロセスになります。
大規模なシステムでは、オペレーティング・システム・カーネルのサイズに対するパラメータ設定の効果を分析します。効果が認められない場合には、アプリケーション・プロセスの数を減らすか、アプリケーションをさらに多くのマシンに分散してMAXACCESSERSを減らします。

 


システム・トラフィックの測定

このトピックには次の項が含まれます:

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におけるボトルネックの検出

UNIXシステムのsar(1)コマンドを使用すると、システムのボトルネックの検出に役立つパフォーマンスについての情報が表示されます。sar(1)コマンドは、次の目的に使用できます。

表4-6は、sar(1)コマンドのオプションの説明です。

表4-6 sar(1)コマンドのオプション
オプション
説明
-u
CPUの使用率を示します。ユーザー・モード、システム・モード、待機状態(ブロックI/Oを待つプロセスを持ったままアイドル状態)、およびアイドル状態である時間を割合で示します。
-b
バッファのアクティビティ(システム・バッファとディスクまたはほかのブロック・デバイスとの間で送信される1秒当たりのデータ転送数など)を報告します。
-c
システム・コールのアクティビティを報告します。これには、すべての種類のシステム・コールと、fork(2)やexec(2)などの特定のシステム・コールが含まれます。
-w
システムのスワッピング・アクティビティをモニターします。これは、スワップ・インとスワップ・アウトの転送数などです。
-q
専有時のキューの長さの平均および専有時間の割合を報告します。
-m
メッセージとシステム・セマフォのアクティビティ(1秒当たりのプリミティブの数)を報告します。
-p
ページング・アクティビティ(アドレス変換ページ・フォルト、ページ・フォルトと保護エラー、およびフリー・リストに再利用された有効ページなど)を報告します。
-r
未使用のメモリー・ページとディスク・ブロック(ユーザー・プロセスで使用できる平均ページ数、プロセス・スワッピングに対して使用できるディスク・ブロックなど)を報告します。

注: 一部のUNIXプラットフォームでは、sar(1)コマンドはありませんが、かわりに同等のコマンドが用意されています。たとえば、BSDではiostat(1)コマンドが用意されています。Sun Microsystems, Inc.ではperfmeter(1)が用意されています。

Windowsにおけるボトルネックの検出

Windowsでシステム情報を収集しボトルネックを検出するには、パフォーマンス・モニターを使用します。「スタート」メニューの「設定」をポイントして「コントロール・パネル」をクリックします。次に、「管理ツール」の「パフォーマンス」をクリックします。


  先頭に戻る       前  次