| ドキュメントのダウンロード | サイトマップ | 用語集 | |
|
|||
| bea ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > Tuxedo > Tuxedo CORBA アプリケーションのスケーリング、分散、およびチューニング > CORBA アプリケーションのチューニング |
|
Tuxedo CORBA アプリケーションのスケーリング、分散、およびチューニング
|
CORBA アプリケーションのチューニング
ここでは、以下の内容について説明します。
BEA Tuxedo アプリケーションの監視の詳細については、『BEA Tuxedo アプリケーション実行時の管理』の「BEA Tuxedo アプリケーションの監視」を参照してください。
アプリケーション資源の最大化
次の領域で正しい判断を行うことで、BEA Tuxedo アプリケーションの機能が向上します。
MSSQ セットを使用すべき場合 (BEA Tuxedo ATMI サーバのみ)
注記 複数サーバ、単一キュー (MSSQ) セットは、BEA Tuxedo CORBA サーバではサポートされていません。
表 4-1 では、BEA Tuxedo サーバで MSSQ セットを使用する場合について説明します。
次の 2 つの例で、MSSQ セットの使用が適している場合と適さない場合がある理由を示します。
システム制御のロード・バランシングの有効化
BEA Tuxedo では、システム全体に対し、ロード・バランシングのアルゴリズムを使用するかどうかを制御できます。ロード・バランシングを使用すると、ロード・ファクタがシステム内の各サービスに適用され、各サーバの負荷の合計を監視できます。各サービス要求は、負荷が最も少ない適切なサーバに送信されます。
注記 BEA Tuxedo CORBA システムでは、システム制御のロード・バランシングは自動的に有効化されます。LDBAL=N を指定しても、ロード・バランシングを無効化することはできません。
SERVICES セクションにあるロード・ファクタの割り当て方法を決定するには、アプリケーションを継続的に動作させて、各サービスの実行にかかる平均時間を計算します。算出した平均時間を必要とするサービスの場合は、LOAD 値に 50 (LOAD=50) を割り当てます。算出した平均値よりも長い時間がかかるサービスの場合は、LOAD>50 とします。算出した平均値より短い時間で済むサービスの場合は、LOAD<50 とします。
実行された各サービスにには、ロード・ファクタ (LOAD) が割り当てられます。これにより、各サーバが実行したサービスの負荷の合計がトラッキングされます。各サービス要求は、負荷の合計が最も低いサーバにルーティングされます。ルーティング先のサーバの負荷合計は、要求されたサービスの LOAD ファクタ分だけ増加します。
また、インターフェイスにも LOAD ファクタを適用することができます。LOAD ファクタの詳細については、『BEA Tuxedo アプリケーション実行時の管理』の「コンフィギュレーション・ファイルの作成」を参照してください。
複製されたサーバ・プロセスおよびグループのコンフィギュレーション
複製されたサーバ・プロセスおよびグループを BEA Tuxedo ドメイン内でコンフィギュレーションするには、次の手順に従います。
マルチスレッド・サーバのコンフィギュレーション
ここでは、以下の内容について説明します。
マルチスレッド・サーバの詳細については、マルチスレッド・サーバの使用を参照してください。
データベースの相互運用のための 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 ファイルで設定します。
注記 MAXOBJECTS パラメータは特にスレッドに適用するものではありませんが、このパラメータを増やしたほうがよい場合があります。マルチスレッド・アプリケーションは、任意の時点において、シングル・スレッド・アプリケーションよりも多くのオブジェクトを活性化する可能性があるためです。
これらのパラメータの設定方法については、次のトピックを参照してください。
インターフェイスへの優先順位の割り当て
ここでは、以下の内容について説明します。
インターフェイスに割り当てる優先順位について
PRIO パラメータを使用して、BEA Tuxedo インターフェイスに優先順位を割り当てることにより、アプリケーション内のデータ・フローを有効に制御できます。BEA 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 パラメータの特性は、次のとおりです。
優先順位を割り当てることで、最も重要な要求の処理はより効率的に行い、重要性の低い要求の処理は遅らせて行うことができます。また、特定のユーザまたは特定の状況に対して優先順位を付けることも可能です。
サーバへのサービスのバンドル (BEA Tuxedo ATMI サーバのみ)
ここでは、以下の内容について説明します。
サービスのバンドルについて
複数のサービスをサーバの実行可能ファイルにパッケージ化する最も簡単な方法は、まったくパッケージ化しないことです。しかし、サービスをパッケージ化しないと、サーバの実行可能ファイル、メッセージ・キューおよびセマフォの数が許容範囲を超える原因となります。サービスをまったくバンドルしない (まとめない) 場合と細かくバンドルする (まとめる) 場合では、それぞれ長所と短所があります。
サービスのバンドルが必要な場合
サービスをバンドルする理由は、以下のとおりです。
性能オプション
BEA Tuxedo のリリース 8.0 から、性能オプションが追加されました。これらのオプションにより、BEA Tuxedo のインフラストラクチャで特定の機能を無効化できます。無効化するのは、CORBA または ATMI アプリケーションで必要でない機能のみとしてください。表 4-3 で、これらのオプションを説明します。
アプリケーション・パラメータによる効率の向上
ここでは、以下の内容について説明します。
これらのアプリケーション・パラメータを設定することにより、システム効率を向上できます。
MAXDISPATCHTHREADS
MAXDISPATCHTHREADS パラメータは、各サーバ・プロセスで生成される、同時に実行できるディスパッチ・スレッドの最大数を決定します。このパラメータを指定する際には、次の事項を考慮してください。
MAXDISPATCHTHREADS パラメータの値は、ほかのパラメータにも影響を与えます。たとえば、MAXACCESSORS パラメータは BEA Tuxedo システムへの同時アクセス数を制御します、各スレッドは、1 つのアクセサとしてカウントされます。マルチスレッド・サーバのアプリケーションの場合、各サーバの実行がコンフィギュレーションされているシステム管理のスレッドの数を考慮しておく必要があります。システム管理のスレッドとは、アプリケーションで開始され管理されるスレッドに対して、BEA Tuxedo ソフトウェアで開始され管理されるスレッドです。内部では BEA Tuxedo が、利用可能なシステム管理のスレッドのプールを管理しています。クライアント要求が受信されると、スレッド・プールから利用可能なシステム管理のスレッドがその要求を実行するように、スケジューリングされています。要求が完了すると、システム管理のスレッドは利用可能なスレッドのプールに返されます。
たとえば、システム内に 4 つのマルチスレッド・サーバがあり、各サーバが 50 個のシステム管理のスレッドを実行するようにコンフィギュレーションされている場合、これらのサーバにおけるアクセサ要件は、次のように計算される、アクセサ数の合計となります。
50 + 50 + 50 + 50 = 200 アクセサ
MINDISPATCHTHREADS
サーバが最初にブートされたときに開始されるサーバ・ディスパッチ・スレッドの数を指定するには、MINDISPATCHTHREADS パラメータを使用します。このパラメータを指定する際には、次の事項を考慮してください。
MAXACCESSERS、MAXOBJECTS、MAXSERVERS、MAXINTERFACES、および MAXSERVICES パラメータの設定
MAXACCESSERS、MAXOBJECTS、MAXSERVERS、MAXINTERFACES、および MAXSERVICES の各パラメータを使用すると、セマフォおよび共用メモリのコストが増大するため、システムの要求を満たす最低限の値を選択してください。また、システムに同時にアクセスできるクライアント数を設定できるようにしておく必要もあります。これらのパラメータには、デフォルトで IPC 資源が適度に割り当てられています。しかし、アプリケーションにとって必要最低限の値を設定するのが賢明です。
マルチスレッド・サーバの場合、各サーバの実行がコンフィギュレーションされているスレッドの数を考慮しておく必要があります。MAXACCESSERS パラメータは、BEA Tuxedo システムの同時アクセサの最大数を設定します。アクセサには、ネイティブおよびリモートのクライアント、サーバ、および管理プロセスが含まれます。MAXACCESSERS パラメータの設定の詳細については、MAXDISPATCHTHREADSを参照してください。
MAXGTT、MAXBUFTYPE、および MAXBUFSTYPE パラメータの設定
システム内のクライアント数に、それらのクライアントがトランザクションをコミットする回数のパーセンテージを掛けた値が 100 に近い場合には、MAXGTT パラメータの値を大きくする必要があります。MAXGTT の値を大きくした場合には、それに応じて、各マシンの TLOGSIZE の値も大きくする必要があります。分散トランザクションを使用しないアプリケーションの場合は、MAXGTT を 0 に設定します。
アプリケーションで受け付けられるバッファのタイプおよびサブタイプの数はそれぞれ、MAXBUFTYPE パラメータおよび MAXBUFSTYPE パラメータで制限できます。MAXBUFTYPE の現在のデフォルト値は 16 です。ユーザ定義のバッファ・タイプが多数指定されていない限り、MAXBUFTYPE は省略できます。しかし、何種類もの VIEW サブタイプを使用する予定がある場合は、MAXBUFSTYPE の設定を、現在のデフォルト値である 32 より増やしておきます。
SANITYSCAN、BLOCKTIME、BBLQUERY、および DBBLWAIT パラメータの設定
システムが、使用率が高いなどの理由で処理の遅いプロセッサで稼動している場合は、タイミング・パラメータである SANITYCAN、BLOCKTIME、およびトランザクションのタイムアウト値を増やします。ネットワークの動作が遅い場合は、BLOCKTIME、BBLQUERY および DBBLWAIT パラメータの値を増やします。
アプリケーション・パラメータの設定
表 4-4 では、アプリケーションのチューニングに使用できるシステム・パラメータを説明します。
IPC 要件の決定
IPC 要件は、さまざまなシステム・パラメータの値で決まります。tmboot -c コマンドを使用すると、コンフィギュレーションの IPC 要件をテストできます。次のパラメータの値は、アプリケーションの IPC 要件に影響をもたらします。
表 4-5 では、アプリケーションで必要とされる IPC に影響を与えるシステム・パラメータについて説明します。
システム・トラフィックの測定
ここでは、以下の内容について説明します。
BEA Tuxedo アプリケーションの監視とトラフィック測定の詳細については、『BEA Tuxedo アプリケーション実行時の管理』の「BEA Tuxedo アプリケーションの監視」を参照してください。
システム・トラフィックとボトルネックについて
トラフィックの量が資源容量の上限に近くなると、システムにボトルネックが生じる可能性があります。サービス・トラフィックを測定するには、インプリメンテーション・コードでグローバル・カウンタを使用します。
たとえば Tuxedo アプリケーションでは、ブート時に tpsvrinit() が呼び出されると、グローバル・カウンタを初期化して、開始時間を記録できます。以降、特定のサービスが呼び出されるたびにカウンタ値は増加します。tpsvrdone() 関数を呼び出してサーバをシャットダウンすると、最終カウンタ値と終了時間が記録されます。このメカニズムにより、一定期間に特定サービスのビジー状態がどの程度であるかを判断できます。
注記 CORBA C++ アプリケーションの場合は、Server::initialize() オペレーションと Server::release() オペレーションを使用します。
BEA 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) コマンドのオプションを説明します。
注記 UNIX プラットフォームの中には、sar(1) コマンドの代わりに別のコマンドが用意されているものもあります。たとえば、BSD には iostat(1) コマンド、Sun Microsystems, Inc. には perfmeter(1) が用意されています。 Windows におけるボトルネックの検出 Windows でシステム情報を収集しボトルネックを検出するには、パフォーマンス・モニタを使用します。[スタート] メニューの [設定] をポイントして [コントロール パネル] をクリックします。次に、[管理ツール] の [パフォーマンス] をクリックします。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
