| ドキュメントのダウンロード | サイトマップ | 用語集 | |
|
|||
| bea ホーム | 製品 | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > Tuxedo > Tuxedo アプリケーション実行時の管理 > BEA Tuxedo ATMI アプリケーションのチューニング |
|
Tuxedo アプリケーション実行時の管理
|
BEA Tuxedo ATMI アプリケーションのチューニング
ここでは、次の内容について説明します。
注記 BEA Tuxedo CORBA 環境でのアプリケーションのチューニングについては、『BEA Tuxedo CORBA アプリケーションのスケーリング、分散、およびチューニング』を参照してください。
MSSQ セットの使用
注記 BEA Tuxedo CORBA サーバでは、MSSQ セット (複数サーバ、単一キュー) がサポートされていません。
BEA Tuxedo ATMI 環境で MSSQ のスキーマを使用すると、ロード・バランシングを行うことができます。1 つのキューには、常に同じサービスを提供する複数のサーバが対応しています。ある要求がサーバのキューに送信され、そのキューが MSSQ セットの一部である場合、メッセージがキューから取り出されて、使用可能な最初のサーバに送られます。このようにして、個々のキューのレベルでロード・バランシングが行われます。
MSSQ を構成するサーバには、そのサーバ固有の応答キューを設定する必要があります。このサーバがほかのサーバに対して要求を行った場合、その応答は要求元のサーバに返されなければなりません。つまり、MSSQ 内のほかのサーバによってキューから取り出されないようにする必要があります。
MSSQ セットを動的に設定し、キューの負荷状況に応じてサーバの生成や削除を自動的に行うことができます。
次の表は、どのような場合に MSSQ セットの使用が適しているかを示しています。
次は、MSSQ セットの使用が適している場合と適さない場合の例を日常生活の中から示しています。
ロード・バランシングの有効化
システム・トラフィックが原因でアプリケーションの性能が低下するのを避けるため、アプリケーション全体に対してロード・バランシング・アルゴリズムを実行できます。ロード・バランシングを使用すると、ロード・ファクタがシステム内の各サービスに適用され、各サーバの負荷の合計を監視できます。各サービス要求は、負荷が最も少ない適切なサーバに送信されます。
システム全体に対してロード・バランシングを実行するには、次の手順に従います。
注記 このアルゴリズムは効果的ですが、コストがかかるため必要な場合にのみ使用してください。アルゴリズムが必要となるのは、2 つ 以上のキューを使用する複数のサーバによってサービスが提供される場合のみです。1 つのサーバのみによって提供されるサービス、または MSSQ (複数サーバ、単一キュー) にある複数のサーバによって提供されるサービスは、ロード・バランシングを必要としません。
サービスの実行時間の測定
サービスの実行時間は、以下のどちらかの方法で測定できます。
servopts -r
ログの情報を分析するには、txrpt(1) コマンドを実行します。
servopts(5) および txrpt(1) については、それぞれ『ファイル形式、データ記述方法、MIB、およびシステム・プロセスのリファレンス』と『BEA Tuxedo コマンド・リファレンス』を参照してください。
サービスへの優先順位の割り当て
優先順位を割り当てることにより、アプリケーション内のデータの流れを強力に制御できます。つまり、重要度の高いリクエストに迅速にサービスを提供し、重要度の低いリクエストには後でサービスを提供することができます。また、特定のユーザや特定の状況に応じて、いつでも優先順位を設定することができます。
BEA Tuxedo サービスに対する優先順位は、以下のどちらかの方法で割り当てることができます。
優先順位の設定例
たとえば、サーバ 1 が、サービス A、B、および C を提供するとします。サービス A および B の優先順位は 50、サービス C の優先順位は 70 です。サービス C に対するリクエストは、サービス A または B に対するリクエストより常に先にキューから取り出されます。サービス A および B に対するリクエストは、互いに等しくキューから取り出されます。システムは、10 回に 1 回の割合で FIFO (first-in、first-out) 順序でリクエストをキューから取り出し、メッセージがキューで無制限に待機しないようにします。
PRIO パラメータを使用して性能を高める
PRIO は、サーバのキュー内にあるサービスの優先順位を決定するパラメータです。ただし、このパラメータの使用には注意が必要です。いったん優先順位が割り当てられると、キューからのメッセージの取り出しに時間がかかる場合があります。キューのメッセージの順序によっては、頻繁に取り出されないメッセージもあります。たとえば、キュー内に A、B、C の 3 つのメッセージがあり、C に対して 10 回以上のリクエストが送信されると、A と B は、10 回中 1 回しかキューから取り出されません。つまり、サービスの性能が低下し、ターンアラウンド・タイムが遅くなる可能性があります。
PRIO パラメータを使用するかを決定する場合は、以下の点を考慮してください。
複数のサービスをサーバへバンドルする
複数のサービスをサーバにパッケージ化する最も簡単な方法は、まったくパッケージしないことです。しかし、サービスをパッケージ化しないと、サーバ、メッセージ・キューおよびセマフォの数が許容範囲を超える原因となります。サービスをまったくバンドルしない (まとめない) 場合と細かくバンドルする (まとめる) 場合では、それぞれ長所と短所があります。
サービスのバンドルが必要な場合
次のうち、いずれかの状況または条件に当てはまる場合は、サービスをバンドルする (まとめる) ことをお勧めします。
同じサーバに、お互いを呼び出すサービス (呼び出し依存型サービス) を 2 つ以上設定しないでください。このサービスを設定すると、サーバは自身を呼び出し、デッドロックの原因となります。
システム全体のパフォーマンスの向上
パフォーマンスを向上するための以下の方法は、BEA Tuxedo リリース 8.0 以降で適用できます。
サービスとインターフェイスをキャッシュする
BEA Tuxedo リリース 8.0 以降では、サービス・エントリとインターフェイス・エントリをキャッシュして、掲示板をロックせずに、キャッシュされたサービスやインターフェイスのコピーを使用することができます。これによってパフォーマンスが大幅に向上します。特に、クライアント数が多く、サービスの数が少ないシステムで有効です。
コンフィギュレーション・ファイルの MACHINCES および SERVERS セクションに追加された SICACHEENTRIESMAX オプションを使用すると、プロセスやサーバ側で保持できるサービス・キャッシュ・エントリの最大数を指定できます。
クライアントやアプリケーションによっては、キャッシュが効果的でない場合があるため、キャッシュ・サイズを制御する環境変数 TMSICACHEENTRIESMAX が追加されています。また、TMSICACHEENTRIESMAX にはデフォルト値が設定されているため、以前のバージョンからアップグレードする場合は新たに設定を変更する必要がありません。キャッシュ・サイズの肥大化はクライアントにとって望ましくないため、TMSICACHEENTRIESMAX を使用してキャッシュ・エントリ数を制御することもできます。
サービス・キャッシュの制限事項
キャッシュ機能には以下の制限事項があります。
注記 SICACHEENTRIESMAX オプションの詳細については、『ファイル形式、データ記述方法、MIB、およびシステム・プロセスのリファレンス』の UBBCONFIG(5) および TM_MIB(5) のセクションを参照してください。
TMSICACHEENTRIESMAX 変数の詳細については、『ファイル形式、データ記述方法、MIB、およびシステム・プロセスのリファレンス』の tuxenv(5) のセクションを参照してください。
認可および監査によるセキュリティを削除する
BEA Tuxedo リリース 7.1 では、AAA (Authentication、Authorization、Auditing) セキュリティ機能が追加され、AAA プラグイン関数を使用したインプリメンテーションでは BEA Tuxedo の管理オプションによるセキュリティをベースにする必要がなくなりました。この結果、BEA Tuxedo 7.1 の主要なコード・パスでは、BEA Engine の AAA セキュリティ関数が常に呼び出されます。しかし、多くのアプリケーションではセキュリティ機能が使用されないため、BEA Engine のセキュリティ呼び出しによるオーバーヘッドは不要です。
BEA Tuxedo リリース 8.0 以降では、コンフィギュレーション・ファイルの RESOURCES セクションの OPTIONS パラメータに、NO_AA オプションが追加されています。NO_AA オプションを使用すると、認可および監査に関するセキュリティ関数の呼び出しを回避できます。認証はほとんどのアプリケーションで必要であるため、この機能をオフにすることはできません。
NO_AA オプションを有効にすると、以下の SECURITY パラメータ が影響を受けます。
注記 NO_AA オプションの詳細については、『ファイル形式、データ記述方法、MIB、およびシステム・プロセスのリファレンス』の UBBCONFIG(5) および TM_MIB(5) のセクションを参照してください。
マルチスレッド化されたブリッジを使用する
ブリッジ・プロセスは、マルチ・マシン Tuxedo ドメイン内のホスト・マシンごとに 1 つずつ実行されます。このため、あるホスト・マシンからドメイン内のほかのホスト・マシンへのトラフィックは、すべて同じブリッジ・プロセスを通して送信されます。ブリッジ・プロセスでは、シングルスレッド実行機能とマルチスレッド実行機能がサポートされています。マルチスレッド化されたブリッジ処理を使用すると、データ・スループットを向上できる場合があります。マルチスレッド化されたブリッジ処理を有効にするには、UBBCONFIG ファイルの MACHINES セクションの BRTHREADS パラメータを設定します。
BRTHREADS=Y と設定すると、ブリッジ・プロセスはマルチスレッドで実行されます。BRTHREADS=N と設定するか、デフォルトの N のままにすると、ブリッジ・プロセスはシングルスレッドで実行されます。
ローカル・マシンを BRTHREADS=Y に、リモート・マシンを BRTHREADS=N に設定することも可能ですが、この場合のマシン間のスループットはシングルスレッド化されたブリッジ・プロセスより劣ります。
BRTHREADS パラメータを使用する際は、以下の点にも注意してください。
注記 Tuxedo マルチ・マシン・ドメインでは、BRTHREADS=Y に設定しても、旧バージョンの Tuxedo が稼働するマシンには影響しません。
マルチスレッド化されたブリッジの詳細については、『ファイル形式、データ記述方法、MIB、およびシステム・プロセスのリファレンス』の UBBCONFIG(5) で説明する MACHINES セクションの BRTHREADS パラメータを参照してください。
マルチスレッド処理をオフにする
BEA Tuxedo は、汎用的なスレッド機能を備えています。ただし、アーキテクチャの汎用性により、重要な状態情報を保護するため、すべての ATMI 呼び出しでミューテックス関数を呼び出す必要がありました。また、ライブラリで使用されるエンジンやキャッシュ・スキーマの階層構造により、さらにミューテックスが必要になります。スレッドを使用しないアプリケーションでは、これらのオプションをオフにすると、アプリケーション・コードを変更しなくても大幅にパフォーマンスを向上させることができます。
マルチスレッド処理をオフにするには、TMNOTHREADS 環境変数を使用します。この環境変数を設定することにより、新たに API 関数やフラグを導入しなくても、個々のプロセスでスレッドをオンまたはオフにすることができます。
TMNOTHREADS=Y に設定すると、ミューテックス関数の呼び出しが回避されます。
注記 TMNOTHREADS の詳細については、『ファイル形式、データ記述方法、MIB、およびシステム・プロセスのリファレンス』の tuxenv(5) のセクションを参照してください。
XA トランザクションをオフにする
すべての BEA Tuxedo アプリケーションで XA トランザクションを使用するのではないにもかかわらず、すべてのプロセスで、内部トランザクション関数の呼び出しによってトランザクション処理の負担がかかります。BEA Tuxedo リリース 8.0 以降では、XA トランザクションを使用しないアプリケーションでパフォーマンスを向上させるため、コンフィギュレーション・ファイルの RESOURCES セクションの OPTIONS パラメータに NO_XA フラグが追加されています。
NO_XA フラグをセットすると、XA トランザクションは許可されなくなります。NO_XA オプションが指定されている場合、GROUPS セクションで TMS サービスを設定しようとすると失敗するので注意してください。
注記 NO_XA オプションの詳細については、『ファイル形式、データ記述方法、MIB、およびシステム・プロセスのリファレンス』の UBBCONFIG(5) および TM_MIB(5) のセクションを参照してください。
システムの IPC 要件の決定
システムの IPC 要件は、以下のシステム・パラメータを使用して決定します。
tmboot -c コマンドを使用すると、コンフィギュレーションの IPC に関する最低条件を表示できます。
次の表は、このようなシステム・パラメータの説明です。
IPC パラメータの調整
以下のアプリケーション・パラメータを設定すると、システムの効率を高めることができます。
MAXACCESSERS、MAXSERVERS、MAXINTERFACES、および MAXSERVICES パラメータの設定
MAXACCESSERS、MAXSERVERS、MAXINTERFACES、および MAXSERVICES の各パラメータを設定すると、セマフォと共用メモリにかかる負担が増えます。これらのパラメータを使用する前にはこの点を考慮し、システムのニーズを満たす最適な値を設定する必要があります。将来システムを移行する場合に備え、余分な資源を確保しておくことも必要です。また、システムに同時にアクセスできるクライアント数を設定できるようにしておく必要もあります。これらのパラメータには、デフォルトで IPC 資源が適度に割り当てられていますが、必要最低限の値を設定するのが賢明です。
MAXGTT、MAXBUFTYPE、および MAXBUFSTYPE パラメータの設定
デフォルト値がアプリケーションで適切かどうかを判断するには、システム内のクライアント数とそれらのクライアントがトランザクションにコミットする時間の割合を掛けた値を算出します。この値が 100 に近い場合は、MAXGTT パラメータ値を増やす必要があります。MAXGTT パラメータの値を増やすと、次のような結果になります。
アプリケーションで使用するバッファ型の数を制限するには MAXBUFTYPE パラメータを設定し、バッファのサブタイプの数を制限するには MAXBUFSTYPE パラメータを設定します。MAXBUFTYPE の現在のデフォルト値は 16 です。ユーザ定義のバッファ型を 8 つ以上作成する予定がある場合は、MAXBUFTYPE に高い数値を設定してください。このパラメータの値を特に指定しない場合は、デフォルト値が使用されます。
MAXBUFSTYPE の現在のデフォルト値は 32 です。多くの VIEW サブタイプを使用する予定がある場合は、このパラメータに高い数値を設定してください。
SANITYSCAN、BLOCKTIME、BBLQUERY、および DBBLWAIT パラメータの設定
システムが遅いプロセッサで稼動している場合 (使用率が高い場合など) 時間間隔を調整するタイミング・パラメータである SANITYCAN、BLOCKTIME、およびトランザクションのタイムアウト値を増やします。
ネットワークの動作が遅い場合は、BLOCKTIME、BBLQUERY および DBBLWAIT パラメータの値を増やします。
チューニング関連パラメータの推奨値
次の表は、アプリケーションのチューニングに使用するシステム・パラメータと推奨値です。
システム・トラフィックの測定
一定の交通量がある道路では渋滞が起こるように、システムでも同様にボトルネックが発生します。実際の高速道路を走る車両数は、道路に渡されたケーブルによってカウントされます。つまり、このケーブルの上を車両が通過するたびに、カウンタの値が増加します。
これと同様に、サービスのトラフィックを測定することができます。たとえば、サーバの起動時 ( tpsvrinit() の呼び出し時) に、グローバル・カウンタを初期化して開始時間を記録することができます。以降、特定のサービスが呼び出されるたびにカウンタ値は増加します。tpsvrdone() 関数を呼び出してサーバをシャットダウンすると、最終カウンタ値と終了時間が記録されます。このメカニズムにより、一定期間に特定サービスのビジー状態がどの程度であるかを判断できます。
BEA Tuxedo システムでは、問題のあるデータ・フローのパターンが原因でボトルネックが生じます。ボトルネックを検出する最も早い方法は、関連するサービスに要する時間をクライアント側から測定することです。
システム・ボトルネックの検出方法
たとえば、クライアント 1 が結果を出力すると 4 秒かかるとします。time() を呼び出すと、サービス A に対する tpcall が動作を 3.7 秒遅らせていることがわかり、さらにサービス A を開始点と終了点で監視すると、その動作に 0.5 秒かかっています。tmadmin の pq コマンドを使用すると、キューがいっぱいであることがわかります。
一方、サービス A の実行に 3.2 秒かかるとします。サービス A の個々の部分はまとめて測定できます。サービス A がサービス B に対して tpcall を発行し、この動作に 2.8 秒かかっていることも考えられます。この場合、キュー時間またはメッセージ送信ブロッキング時間を分離できます。適切な時間を識別すると、アプリケーションはトラフィックの処理に戻されます。
time() を使用すると、次の項目の所要時間を測定できます。
UNIX プラットフォームにおけるボトルネックの検出
UNIX システムの sar(1) コマンドを使用すると、システムのボトルネックの検出に役立つ性能に関する情報が表示されます。sar(1) は、次の目的に使用できます。
次の表は、sar(1) コマンドのオプションの説明です。
注記 UNIX システムの中には、sar(1) コマンドの代わりに別のコマンドが用意されているものもあります。たとえば、BSD には iostat(1) コマンド、Sun には perfmeter(1) が用意されています。 Windows 2000 プラットフォームにおけるボトルネックの検出 Windows 2000 プラットフォームでは、パフォーマンス・モニタを使用して、システム情報を収集しボトルネックを検出します。パフォーマンス・モニタを開くには、[スタート] メニューから次の項目を選択します。 関連項目
[スタート] -> [プログラム] -> [管理ツール] -> [パフォーマンス モニタ]
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
