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

8.1 MSSQセットの使用

ノート:

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

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

MSSQを構成するサーバーには、そのサーバー固有の応答キューを設定する必要があります。このサーバーがほかのサーバーに対してリクエストを行った場合、その応答はリクエスト元のサーバーに返されなければなりません。つまり、MSSQ内のほかのサーバーによってキューから取り出されないようにする必要があります。

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

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

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

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

MSSQセットが適用できる例は銀行です。銀行には、同じサービスを提供する窓口が複数あり、顧客は1列に並んで空いた窓口へ順に進みます。次に空く窓口が、常に列の次の顧客に応対します。この例では、各窓口がすべての顧客サービスを行うことができなければなりません。これをOracle Tuxedo環境に当てはめると、複数のサーバーが単一のキューを共有する場合、すべてのサーバーで常に同じサービスが提供できなければならないことを示します。MSSQセットの使用により、各キューのレベルでロード・バランシングを実現できます。
MSSQセットが適用できない例は、スーパーマーケットのレジでのサービスです。クレジット・カードを受け付けるレジや、現金のみを受け付けるレジなど、レジごとに支払方法が異なるという図式は、MSSQセットを適用できないOracle Tuxedoアプリケーションに似ています。

親トピック: Oracle Tuxedo ATMIアプリケーションのチューニング

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

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

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

アプリケーションを長時間実行します。
各サービスの実行にかかる平均時間を記録します。
構成ファイルのRESOURCESセクションを次のように設定します。
- LDBALをYに設定します
- 平均値に近い時間がかかるサービスの場合は、LOAD値に50 (LOAD=50)を割り当てます。

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

ノート:
このアルゴリズムは効果的ですが、コストがかかるため必要な場合にのみ使用してください。アルゴリズムが必要となるのは、2つ以上のキューを使用する複数のサーバーによってサービスが提供される場合のみです。1つのサーバーのみによって提供されるサービス、またはMSSQ(複数サーバー、単一キュー)にある複数のサーバーによって提供されるサービスは、ロード・バランシングを必要としません

親トピック: Oracle Tuxedo ATMIアプリケーションのチューニング

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

サービスの実行時間は、以下のどちらかの方法で測定できます。

管理パラメータを使用 - 構成ファイルで、サービスのログが標準エラーに書き込まれるように設定できます。SERVICESセクションで次を指定します。
servopts -r
ログの情報を分析するには、txrpt(1)コマンドを実行します。
servopts(5)およびtxrpt(1)の詳細は、それぞれ『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』と『Oracle Tuxedoコマンド・リファレンス』を参照してください。
プログラムを使用 - サービス・ルーチンの始めと終わりにtime()への呼出しを挿入します。実行時間が最も長いサービスでは負荷が最大になり、実行時間が最も短いサービスでは負荷が最小になります。(time()の詳細は、C言語ライブラリのマニュアルを参照してください。)

親トピック: Oracle Tuxedo ATMIアプリケーションのチューニング

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

優先度を割り当てることにより、アプリケーション内のデータの流れを強力に制御できます。つまり、重要度の高いリクエストにより迅速なサービスを提供し、重要度の低いリクエストにはより遅いサービスを提供します。また、特定のユーザーまたは特定の状況を優先することも可能です。

Oracle Tuxedoサービスに対する優先度は、以下のどちらかの方法で割り当てることができます。

管理パラメータを使用 - 構成ファイルの SERVICES セクションで指定されている各サービスに対し、PRIOパラメータを指定します。
プログラムを使用 - 適切なクライアント・アプリケーションとサーバー・アプリケーションに対してtpsprio()関数への呼出しを追加し、指定されたクライアントとサーバーのみが優先度を動的に変更できるようにします。ただし、選ばれたクライアントだけがサービスの優先度を高く設定できるようにするべきです。サーバーがサービス・リクエストを行うシステムでは、サーバー側からtpsprio()を呼び出し、インタフェースまたはサービスの呼出しの優先度を上げることができます。これによりユーザーは、必要なインタフェースまたはサービス・リクエストを待たずに済みます。

親トピック: Oracle Tuxedo ATMIアプリケーションのチューニング

8.4.1 優先度の設定例

サーバー1は、インタフェースA、B、およびCを提供します。インタフェースAおよびBの優先度は50で、インタフェースCの優先度は70です。インタフェースCに対するリクエストは、AまたはBに対するリクエストより常に先にキューから取り出されます。AおよびBに対するリクエストは、互いに等しくキューから取り出されます。システムは、10回に1回の割合でFIFO (first-in、first-out)の順序でリクエストをキューから取り出し、メッセージがキューで無限に待機しないようにします。

親トピック: インタフェースまたはサービスへの優先度の割当て

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

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

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

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

親トピック: インタフェースまたはサービスへの優先度の割当て

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

複数のサービスをサーバーにパッケージ化する最も簡単な方法は、まったくパッケージしないことです。しかし、サービスをパッケージ化しないと、サーバー、メッセージ・キューおよびセマフォの数が許容範囲を超える原因となります。サービスをまったくバンドルしない(まとめない)場合と細かくバンドルする(まとめる)場合では、それぞれ長所と短所があります。

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

親トピック: Oracle Tuxedo ATMIアプリケーションのチューニング

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

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

サービスの機能が類似している - アプリケーション内に類似するサービスが複数ある場合は、それらのサービスを同じサーバーにバンドルできます。アプリケーション側は指定されたときに、すべてを提供するか、あるいは何も提供しません。たとえば、bankappアプリケーションの例では、WITHDRAW、DEPOSIT、INQUIRYの3つのサービスを、窓口のオペレーションを扱うサーバーにグループ化できます。このように内容の似たサービスをまとめると、サービスを管理しやすくなります。
類似するライブラリがある - 同じライブラリを使用するサービスをバンドルすると、ディスク領域を節約できます。たとえば、同じ100Kのライブラリを使用する3つのサービスと、異なる100Kのライブラリを使用する3つのサービスがある場合、最初の3つのサービスをバンドルすると200Kの領域を節約できます。たいていの場合、同等の機能を持つサービスには類似するライブラリがあります。
キュー - キューで処理できる範囲のサービスのみをサーバーにバンドルしてください。空のMSSQセットに追加された各サービスは、サーバーの実行可能モジュールのサイズにはあまり影響しません。また、システム上のキューの数にはまったく影響しません。ただし、キューがいっぱいになるとシステムのパフォーマンスは低下するため、対応策として別のサーバーの実行可能モジュールを作成する必要があります。

ノート:

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

親トピック: 複数のサービスをサーバーへバンドルする

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

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

親トピック: Oracle Tuxedo ATMIアプリケーションのチューニング

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

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

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

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

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

親トピック: システム全体のパフォーマンスの向上

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

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

サービスにルーティング基準がある場合、そのサービスはキャッシュされません。
サービスにバッファ型の制限がある場合、そのサービスはキャッシュされません。
サービスのグループがあらかじめ指定されている場合(TMSサービス)、そのサービスはキャッシュされません。
サービス・エントリの数がゼロの場合、キャッシュ処理は実行されません。

ノート:

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

親トピック: サービスとインタフェースをキャッシュする

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

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)に関する項を参照してください

親トピック: システム全体のパフォーマンスの向上

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

ブリッジ・プロセスは、マルチ・マシンTuxedoドメイン内のホスト・マシンごとに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パラメータに関する項を参照してください。

親トピック: システム全体のパフォーマンスの向上

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

Oracle Tuxedoは、汎用的なスレッド機能を備えています。ただし、アーキテクチャの汎用性により、重要な状態情報を保護するため、すべてのATMI呼出しでミューテックス関数を呼び出す必要がありました。また、ライブラリで使用されるエンジンやキャッシュ・スキームの階層構造により、さらにミューテックスが必要になります。スレッドを使用しないアプリケーションでは、これらのオプションをオフにすると、アプリケーション・コードを変更しなくても大幅にパフォーマンスを向上させることができます。

マルチスレッド処理をオフにするには、TMNOTHREADS環境変数を使用します。この環境変数を設定することにより、新たにAPI関数やフラグを導入しなくても、個々のプロセスでスレッドをオンまたはオフにすることができます。

TMNOTHREADS=Yに設定すると、ミューテックス関数の呼出しが回避されます。

ノート:

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

親トピック: システム全体のパフォーマンスの向上

8.6.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)の項を参照してください。

親トピック: システム全体のパフォーマンスの向上

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

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

MAXACCESSERS
REPLYQ
RQADDR
MAXSERVERS
MAXSERVICES
MAXGTT

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

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

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

パラメータ説明

MAXACCESSSERS セマフォの数を指定します。メッセージ・キューの数は、「MAXACCESSERS +応答キューを持つサーバー数(MSSQセットのサーバー数 * MSSQセット数)」とほぼ同じです。

MAXSERVERS、MAXSERVICESおよびMAXGTT MAXSERVERS、 MAXSERVICES、MAXGTTの3つ、およびROUTING、GROUP、NETWORKの3つのセクションの全体のサイズは共有メモリーのサイズに影響し、これらのパラメータの相関関係を計算式に表そうとすると複雑になります。かわりに、単純にtmboot -cまたはtmloadcf -cを実行すると、アプリケーションで最低限必要なIPCのリソース要件を計算することができます。

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

キューに関連するカーネル・パラメータ

クライアントとサーバー間のバッファ・トラフィックのフローを管理するためにチューニングします。キューの最大サイズ(バイト単位)は、アプリケーションで最も大きいメッセージを処理できる大きさに設定します。通常、キューの75 - 85%は使用中です。この割合が低いとキューが無駄になり、割合が高いとメッセージ送信が頻繁にブロックされる原因になります。

アプリケーションが送信するメッセージに対して最大のバッファを処理できるように最大サイズを設定します。

最大キュー長(キューに同時にとどまることができる最大メッセージ数)は、アプリケーションにおける操作に適した大きさに設定する必要があります。

キューの平均使用率と平均長を測定するには、アプリケーションをシミュレートするか、または実行します。これにより、アプリケーションの実行前にチューニング可能なパラメータを評価でき、アプリケーションのパフォーマンス分析後にアプリケーションを正しくチューニングできます。

大規模なシステムでは、オペレーティング・システム・カーネルのサイズに対するパラメータ設定の効果を分析します。効果が認められない場合には、アプリケーション・プロセスの数を減らすか、またはアプリケーションをさらに多くのマシンに分散してMAXACCESSERSを減らします。

親トピック: Oracle Tuxedo ATMIアプリケーションのチューニング

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

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

MAXACCESSERS、MAXSERVERS、MAXINTERFACES、MAXSERVICES
MAXGTT、MAXBUFTYPE、MAXBUFSTYPE
MAXGTT、MAXBUFTYPE、MAXBUFSTYPE
SANITYSCAN、BLOCKTIMEおよび個々のトランザクション・タイムアウト値
BBLQUERY、DBBLWAIT

親トピック: Oracle Tuxedo ATMIアプリケーションのチューニング

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

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

親トピック: IPCパラメータのチューニング

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

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

コミットの速度によっては、クライアントの数を増やす必要があります。
マシンによっては、TLOGSIZEの値を増やす必要があります。
分散型のトランザクションを使用しないアプリケーションでは、MAXGTTを0に設定する必要があります。

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

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

親トピック: IPCパラメータのチューニング

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

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

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

親トピック: IPCパラメータのチューニング

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

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

パラメータ	値
`MAXACCESSERS、MAXSERVERS、MAXINTERFACES、MAXSERVICES`	必要最低限の値を設定します(IPCコストの関係上)。(クライアントを追加できるように設定します。)
`MAXGTT、MAXBUFTYPE、MAXBUFSTYPE`	`MAXGTT`の値を増やして、多数のクライアントを許容します。トランザクション処理を行わないアプリケーションでは、`MAXGTT`を0に設定します。ユーザー定義のバッファ型を8つ以上作成する場合にかぎり、`MAXBUFTYPE`を使用します。多くの種類の`VIEWサブタイプを使用する場合は、MAXBUFSTYPE`の値を増やします。
`BLOCKTIME、TRANTIME、SANITYSCAN`	システムの動作が遅い場合は、値を増やします。
`BLOCKTIME、TRANTIME、BBLQUERY、DBBLWAIT`	ネットワークの動作が遅い場合は、値を増やします。

親トピック: IPCパラメータのチューニング

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

一定の交通量がある道路では渋滞が起こるように、システムでも同様にボトルネックが発生します。実際の高速道路を走る車両数は、道路に渡されたケーブルによってカウントされます。つまり、このケーブルの上を車両が通過するたびに、カウンタの値が増加します。

これと同様に、サービスのトラフィックを測定することができます。たとえば、サーバーの起動時(tpsvrinit()の呼出し時)に、グローバル・カウンタを初期化して開始時間を記録することができます。以降、特定のサービスが呼び出されるたびにカウンタ値は増加します。tpsvrdone()関数を呼び出してサーバーを停止すると、最終カウンタ値と終了時間が記録されます。このメカニズムにより、一定期間に特定サービスのビジー状態がどの程度であるかを判断できます。

Oracle Tuxedoシステムでは、問題のあるデータ・フローのパターンが原因でボトルネックが生じます。ボトルネックを最も迅速に検出する方法は、関連するサービスに要する時間をクライアント側から測定することです。

親トピック: Oracle Tuxedo ATMIアプリケーションのチューニング

8.9.1 システム・ボトルネックの検出例

たとえば、クライアント1が結果を出力すると4秒かかるとします。time()を呼び出すと、サービスAに対するtpcallが動作を3.7秒遅らせていることがわかります。サービスAを開始点と終了点でモニターすると、0.5秒かかっています。tmadminのpqコマンドを使用すると、キューがいっぱいであることがわかります。

一方、サービスAの実行に3.2秒かかるとします。サービスAの個々の部分はまとめて測定できます。サービスAがサービスBに対してtpcallを発行し、この動作に2.8秒かかっていることも考えられます。この場合、キュー時間またはメッセージ送信ブロッキング時間を分離できます。適切な時間を識別すると、アプリケーションはトラフィックの処理に戻されます。

time()を使用すると、次の項目の所要時間を測定できます:

クライアント・プログラム全体
単一のクライアント・サービス・リクエスト
サービス機能全体
サービス・リクエストを行うサービス機能(ある場合)

親トピック: システム・トラフィックの測定

8.9.2 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)が用意されています。

親トピック: システム・トラフィックの測定

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

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

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