Oracle Tuxedo ATMIアプリケーションのチューニング

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

•	MSSQセットの使用

•	ロード・バランシングの有効化

•	サービスの実行時間の測定

•	インタフェースまたはサービスへの優先度の割当て

•	複数のサービスをサーバーへバンドルする

•	システム全体のパフォーマンスの向上

•	システムのIPC要件の決定

•	IPCパラメータのチューニング

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

注意:	Oracle Tuxedo CORBA環境でのアプリケーションのチューニングについては、『CORBAアプリケーションのスケーリング、配布およびチューニング』を参照してください。

MSSQセットの使用

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

Oracle Tuxedo ATMI環境でMSSQのスキームを使用すると、ロード・バランシングを実行できます。1つのキューには、常に同じサービスを提供する複数のサーバーが対応しています。あるリクエストがサーバーのキューに送信され、そのキューがMSSQセットの一部である場合、メッセージがキューから取り出されて、使用可能な最初のサーバーに送られます。このようにして、個々のキューのレベルでロード・バランシングが実行されます。

サーバーがMSSQセットの一部である場合は、固有の応答キューを構成する必要があります。このサーバーが他のサーバーに対してリクエストを実行した場合、その応答はリクエスト元のサーバーに返される必要があります。つまり、MSSQセット内の他のサーバーによってキューから取り出されないようにする必要があります。

MSSQセットを動的に設定し、キューの負荷状況に応じてサーバーの生成や削除を自動的に行うことができます。

次の表は、どのような場合にMSSQセットの使用が適しているかを示しています。

 

次の場合はMSSQセットを使用する必要があります. . .	次の場合はMSSQセットを使用しないでください. . .
2 - 12台のサーバーがある。	サーバー数が多すぎる。(MSSQセットを多数使用して対処することも可能です。)
バッファ・サイズが適度な大きさである(1つのキューに十分収まる程度)。	バッファ・サイズが1つのキューでいっぱいになる。
すべてのサーバーが同じサービスのセットを提供する。	サーバーごとにサービスが異なる。
メッセージのサイズが比較的小さい。	キューがいっぱいになるほどサイズの大きいメッセージがサービスに渡される。キューがいっぱいになると、非ブロッキング送信が失敗するか、またはブロッキング送信がブロックされます。
サービスのターンアラウンド・タイムが最適であり、一貫性がある。

次は、MSSQセットの使用が適している場合と適さない場合の例を日常生活の中から示しています。

•	MSSQセットが適用できる例は銀行で、銀行には、同じサービスを提供する窓口が複数あり、1列に並んだ顧客に対応します。次に空く窓口が、常に列の次の顧客に応対します。この例では、各窓口がすべての顧客サービスを行える必要があります。Oracle Tuxedo環境では、単一のキューを共有するように設定されているすべてのサーバーで、常に同じサービスを提供する必要があります。MSSQセットの利点は、各キューのレベルで2つ目のロード・バランシングを実現できることです。

•	MSSQセットが適用できない例は、スーパーマーケットのレジでのサービスです。クレジット・カードを受け付けるレジや、現金のみを受け付けるレジなど、レジごとに支払方法が異なるという図式は、MSSQセットを適用できないOracle Tuxedoアプリケーションに似ています。

ロード・バランシングの有効化

大量のシステム・トラフィックが原因で性能が低下しないようにするため、アプリケーション全体に対してロード・バランシング・アルゴリズムを実行できます。ロード・バランシングを使用すると、ロード・ファクタがシステム内の各サービスに適用され、各サーバーの負荷の合計を追跡できます。各サービス・リクエストは、負荷が最も少ない適切なサーバーに送信されます。

システム全体に対してロード・バランシングを実行するには、次の手順に従います。

1.	アプリケーションを長時間実行します。

2.	各サービスの実行にかかる平均時間を記録します。

3.	構成ファイルのRESOURCESセクションを次のように設定します。

•	LDBALをYに設定します。

•	平均値に近い時間がかかるサービスの場合は、LOAD値に50 (LOAD=50)を割り当てます。

•	平均値より長い時間がかかる場合は、LOAD>50を設定します。平均値より短い時間で済む場合はLOAD<50を設定します。

注意:	このアルゴリズムは効果的ですが、コストがかかるため必要な場合にのみ、つまり複数のキューを使用するサーバーによってサービスが提供される場合にのみ使用してください。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回の割合でfirst-in、first-out (FIFO)順序でリクエストをキューから取り出し、メッセージがキューで無制限に待機しないようにします。

PRIOパラメータを使用してパフォーマンスを向上させる

PRIOは、サーバーのキュー内にあるインタフェースまたはサービスの優先度を決定するパラメータです。ただし、このパラメータの使用には注意が必要です。いったん優先度が割り当てられると、キューからのメッセージの取出しに時間がかかる場合があります。キューのメッセージの順序によっては、頻繁に取り出されないメッセージもあります(たとえば、キュー内にA、B、Cの3つのメッセージがあり、Cに対して10回以上のリクエストが送信されると、AとBは、10回中1回しかキューから取り出されません)。つまり、サービスのパフォーマンスが低下し、ターンアラウンド・タイムが遅くなる可能性があります。

PRIOパラメータを使用するかどうかを決定する場合は、次の点を考慮してください。

•	優先度が高いほうが先に優先権を得るので、通常は、呼出し回数の少ないインタフェースやサービスにのみ高い優先度を割り当てる必要があります。

•	メッセージは、FIFOに基づき10回に1回取り出されるため、優先順位の低いメッセージがキューに無制限にとどまることはありません。インタフェースやサービスに対して低い優先度を割り当てる場合は、これらがレスポンス時間を考慮する必要のないものであることを確認しておく必要があります。

複数のサービスをサーバーへバンドルする

複数のサービスをサーバーにパッケージ化する最も簡単な方法は、まったくパッケージ化しないことです。しかし、サービスをパッケージ化しないと、サーバー、メッセージ・キューおよびセマフォの数が許容範囲を超えることになります。したがって、サービスをバンドルしない場合と細かくバンドルする場合との間にトレードオフがあります。

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

次のうち、いずれかの状況または条件に当てはまる場合は、サービスをバンドルする(まとめる)ことをお薦めします。

•	サービスの機能が類似している - アプリケーション内に類似するサービスが複数ある場合は、それらのサービスを同じサーバーにバンドルできます。アプリケーション側は、指定された時点で、すべてのサービスを提供するか、またはサービスをまったく提供しないかのどちらかを行います。たとえば、bankappアプリケーションの例では、WITHDRAW、DEPOSIT、INQUIRYの3つのサービスを、窓口のオペレーションを扱うサーバーにグループ化できます。このように内容の似たサービスをまとめると、サービスを管理しやすくなります。

•	類似するライブラリがある - 同じライブラリを使用するサービスをバンドルすると、ディスク領域を節約できます。たとえば、同じ100Kのライブラリを使用する3つのサービスと、異なる100Kのライブラリを使用する3つのサービスがある場合、最初の3つのサービスをバンドルすると200Kの領域を節約できます。たいていの場合、同等の機能を持つサービスには類似するライブラリがあります。

•	キュー - キューで処理できる範囲のサービスのみをサーバーにバンドルしてください。空のMSSQセットに追加された各サービスは、サーバーの実行可能モジュールのサイズにはあまり影響しません。また、システム上のキューの数にはまったく影響しません。ただし、キューがいっぱいになるとシステムのパフォーマンスは低下するため、対応策として別のサーバーの実行可能モジュールを作成する必要があります。

同じサーバーに、お互いを呼び出すサービス(呼出し依存型サービス)を2つ以上設定しないでください。このサービスを設定すると、サーバーは自身を呼び出し、デッドロックの原因となります。

システム全体のパフォーマンスの向上

パフォーマンスを向上させるための以下の方法は、Oracle Tuxedoリリース8.0以降で適用できます。

•	サービスとインタフェースをキャッシュする

•	認可および監査によるセキュリティを削除する

•	マルチスレッド処理をオフにする

•	XAトランザクションをオフにする

サービスとインタフェースをキャッシュする

Oracle Tuxedoリリース8.0以降では、サービス・エントリとインタフェース・エントリをキャッシュして、掲示板をロックせずに、キャッシュされたサービスやインタフェースのコピーを使用できます。この機能によってパフォーマンスが大幅に向上し、特に、クライアント数が多く、サービスの数が少ないシステムで有効です。

構成ファイルのMACHINESおよびSERVERSセクションに追加されたSICACHEENTRIESMAXオプションを使用すると、プロセスやサーバー側で保持できるサービス・キャッシュ・エントリの最大数を指定できます。

クライアントやアプリケーションによっては、キャッシュが効果的でない場合があるため、キャッシュ・サイズを制御する環境変数TMSICACHEENTRIESMAXが追加されています。また、TMSICACHEENTRIESMAXにはデフォルト値が設定されているため、以前のバージョンからアップグレードする場合は新たに設定を変更する必要がありません。キャッシュ・サイズの肥大化はクライアントにとって望ましくないため、TMSICACHEENTRIESMAXを使用してキャッシュ・エントリ数を制御することもできます。

サービス・キャッシュの制限事項

キャッシュ機能には以下の制限事項があります。

•	サービスにルーティング基準がある場合、そのサービスはキャッシュされません。

•	サービスにバッファ型の制限がある場合、そのサービスはキャッシュされません。

•	サービスのグループがあらかじめ指定されている場合(TMSサービス)、そのサービスはキャッシュされません。

•	サービス・エントリの数がゼロの場合、キャッシュ処理は実行されません。

注意:	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パラメータが影響を受けます。

•	パラメータNONE、APP_PWおよびUSER_AUTHは正常に動作しますが、認可または監査は行われません。

•	ACLおよびMANDATORY_ACLパラメータは正常に動作しますが、デフォルトのOracleセキュリティ・メカニズムのみが使用されます。

注意:	NO_AAオプションの詳細は、『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のUBBCONFIG(5)およびTM_MIB(5)に関する項を参照してください。

マルチスレッド化されたブリッジを使用する

ブリッジ・プロセスは、マルチ・マシンTuxedoドメイン内のホスト・マシンごとに1つずつ実行されるため、ホスト・マシンからドメイン内の他のホスト・マシンへのトラフィックは、すべて1つのブリッジ・プロセスを通して送信されます。ブリッジ・プロセスでは、シングル・スレッド実行機能とマルチスレッド実行機能がサポートされています。マルチスレッド化されたブリッジ処理を使用すると、データ・スループットを向上できる場合があります。マルチスレッド化されたブリッジ処理を有効にするには、UBBCONFIGファイルのMACHINESセクションのBRTHREADSパラメータを設定します。

BRTHREADS=Yと設定すると、ブリッジ・プロセスはマルチスレッドで実行されます。BRTHREADS=Nと設定するか、デフォルトのNのままにすると、ブリッジ・プロセスはシングル・スレッドで実行されます。

ローカル・マシンをBRTHREADS=Yに、リモート・マシンをBRTHREADS=Nに設定することも可能ですが、この場合のマシン間のスループットはシングル・スレッド化されたブリッジ・プロセスより劣ります。

BRTHREADSパラメータを使用する際は、以下の点にも注意してください。

•	BRTHREADS=Yに設定する意味があるのはマシンが複数のCPUを備えている場合のみですが、複数のCPUを備えていなくてもBRTHREADS=Yに設定することは可能です。

•	UBBCONFIGファイルのRESOURCESセクションのMODELパラメータをSHMに設定した場合、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)に関する項を参照してください。

XAトランザクションをオフにする

すべての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要件の決定

システムのIPC要件は、以下のシステム・パラメータを使用して決定します。

•	MAXACCESSERS

•

REPLYQ

•

RQADDR

•	MAXSERVERS

•	MAXSERVICES

•

MAXGTT

tmboot -cコマンドを使用すると、構成のIPCに関する最低条件を表示できます。

次の表は、このようなシステム・パラメータの説明です。

 

表8-1 IPCリソースのチューニング・パラメータ

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

IPCパラメータのチューニング

以下のアプリケーション・パラメータを設定すると、システムの効率を高めることができます。

•	MAXACCESSERS、MAXSERVERS、MAXINTERFACESおよびMAXSERVICES

•	MAXGTT、MAXBUFTYPEおよびMAXBUFSTYPE

•	SANITYSCAN、BLOCKTIMEおよび個々のトランザクション・タイムアウト値

•	BBLQUERYおよびDBBLWAIT

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

MAXACCESSERS、MAXSERVERS、MAXINTERFACESおよびMAXSERVICESの各パラメータを設定すると、セマフォと共有メモリーにかかる負担が増えます。これらのパラメータを使用する前にはこの点を考慮し、システムのニーズを満たす最適な値を設定する必要があります。将来システムを移行する場合に備え、余分な資源を確保しておくことも必要です。また、システムに同時にアクセスできるクライアント数を設定できるようにしておく必要もあります。これらのパラメータには、デフォルトでIPC資源が適度に割り当てられていますが、必要最低限の値を設定するのが賢明です。

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

デフォルト値がアプリケーションで適切かどうかを判断するには、システム内のクライアント数とそれらのクライアントがトランザクションにコミットする時間の割合を乗算します。この値が100に近い場合は、MAXGTTパラメータの値を増やす必要があります。MAXGTTパラメータの値を増やすと、次のような結果になります。

•	コミットの速度によっては、クライアントの数を増やす必要があります。

•	マシンによっては、TLOGSIZEの値を増やす必要があります。

•	分散型のトランザクションを使用しないアプリケーションでは、MAXGTTを0に設定する必要があります。

アプリケーションで使用するバッファ型の数を制限するにはMAXBUFTYPEパラメータを設定し、バッファのサブタイプの数を制限するにはMAXBUFSTYPEパラメータを設定します。MAXBUFTYPEの現在のデフォルト値は16です。ユーザー定義のバッファ型を8つ以上作成する予定がある場合は、MAXBUFTYPEに高い数値を設定してください。このパラメータの値を特に指定しない場合は、デフォルト値が使用されます。

MAXBUFSTYPEの現在のデフォルト値は32です。多くのVIEWサブタイプを使用する予定がある場合は、このパラメータに高い数値を設定してください。

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

システムが遅いプロセッサで稼働している場合(使用率が高い場合など)時間間隔を調整するタイミング・パラメータであるSANITYCAN、BLOCKTIMEおよびトランザクションのタイムアウト値を増やします。

ネットワークの動作が遅い場合は、BLOCKTIME、BBLQUERYおよびDBBLWAITパラメータの値を増やします。

チューニング関連パラメータの推奨値

次の表は、アプリケーションのチューニングに使用するシステム・パラメータと推奨値です。

 

これらのパラメータを使用します. . .	目的
MAXACCESSERS、MAXSERVERS、MAXINTERFACESおよびMAXSERVICES	IPCリソースを確保するために必要最低限の値を設定します。(クライアントを追加できるようにします。)
MAXGTT、MAXBUFTYPEおよびMAXBUFSTYPE	MAXGTTの値を増やして、多数のクライアントを許容します。非トランザクション型アプリケーションでは、MAXGTTを0に設定します。 ユーザー定義のバッファ型を8つ以上作成する場合にかぎり、MAXBUFTYPEを使用します。 多くの種類のVIEWサブタイプを使用する場合は、MAXBUFSTYPEの値を増やします。
BLOCKTIME、TRANTIMEおよびSANITYSCAN	システムの動作が遅い場合は、値を増やします。
BLOCKTIME、TRANTIME、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プラットフォームにおけるボトルネックの検出

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

•	あらかじめ決められた間隔でオペレーティング・システムの累積アクティビティ・カウンタをサンプリングします。

•	システム・ファイルからデータを抽出します。

次の表に、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にはperfmeter(1)が用意されています。

Windowsプラットフォームにおけるボトルネックの検出

Windowsプラットフォームでは、パフォーマンス・モニターを使用して、システム情報を収集しボトルネックを検出します。パフォーマンス・モニターを開くには、「スタート」メニューから次のオプションを選択します。

「スタート」→「設定」→「制御設定」→「管理ツール」→「パフォーマンス」

関連項目

•	『Oracle Tuxedoアプリケーションの設定』の分散型のATMIアプリケーション用の構成ファイルの作成に関する項

•	『Oracle Tuxedoアプリケーションの設定』の分散アプリケーションのネットワーク設定に関する項

•	4-1ページの「分散アプリケーションにおけるネットワークの管理」

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