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