|
|
| 注: | Oracle Tuxedo CORBA環境でのアプリケーションのチューニングについては、『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)については、それぞれ『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』と『Oracle 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オプションの詳細は、『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のUBBCONFIG(5)およびTM_MIB(5)のセクションを参照してください。 |
| 注: | TMSICACHEENTRIESMAX変数の詳細は、『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』の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オプションの詳細は、『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』の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が稼働するマシンには影響しません。 |
| 注: | マルチスレッド化されたブリッジの詳細は、『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のUBBCONFIG(5)のMACHINESセクションのBRTHREADSパラメータに関する項を参照してください。 |
Oracle Tuxedoは、汎用的なスレッド機能を備えています。ただし、アーキテクチャの汎用性により、重要な状態情報を保護するため、すべてのATMI呼出しでミューテックス関数を呼び出す必要がありました。また、ライブラリで使用されるエンジンやキャッシュ・スキームの階層構造により、さらにミューテックスが必要になります。スレッドを使用しないアプリケーションでは、これらのオプションをオフにすると、アプリケーション・コードを変更しなくても大幅にパフォーマンスを向上させることができます。
マルチスレッド処理をオフにするには、TMNOTHREADS環境変数を使用します。この環境変数を設定することにより、新たにAPI関数やフラグを導入しなくても、個々のプロセスでスレッドをオンまたはオフにすることができます。
TMNOTHREADS=Yに設定すると、ミューテックス関数の呼出しが回避されます。
| 注: | TMNOTHREADSの詳細は、『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のtuxenv(5)のセクションを参照してください。 |
すべてのOracle TuxedoアプリケーションでXAトランザクションを使用するのではないにもかかわらず、すべてのプロセスで、内部トランザクション関数の呼出しによってトランザクション・セマンティクスの負担がかかります。Oracle Tuxedoリリース8.0以降では、XAトランザクションを使用しないアプリケーションでパフォーマンスを向上させるため、構成ファイルのRESOURCESセクションのOPTIONSパラメータにNO_XAフラグが追加されています。
NO_XAフラグをセットすると、XAトランザクションは許可されなくなります。NO_XAオプションが指定されている場合、GROUPSセクションでTMSサービスを設定しようとすると失敗するので注意してください。
| 注: | NO_XAオプションの詳細は、『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のUBBCONFIG(5)およびTM_MIB(5)のセクションを参照してください。 |
システムのIPC要件は、以下のシステム・パラメータを使用して決定します。
tmboot -cコマンドを使用すると、構成のIPCに関する最低条件を表示できます。
クライアントとサーバー間のバッファ・トラフィックのフローを管理するためにチューニングします。キューの最大サイズ(バイト単位)は、アプリケーションで最も大きいメッセージを処理できる大きさに設定します。通常、キューの75 - 85%は使用中です。この割合が低いとキューが無駄になり、割合が高いとメッセージ送信が頻繁にブロックされる原因になります。
|
以下のアプリケーション・パラメータを設定すると、システムの効率を高めることができます。
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プラットフォームでは、パフォーマンス・モニターを使用して、システム情報を収集しボトルネックを検出します。パフォーマンス・モニターを開くには、「スタート」メニューから次の項目を選択します。
Start —> Settings —> Control Settings —> Administration Tools —> Performance
  
|