UNIXシステムでのIPCリソースの構成

UNIX上のOracle Tuxedoシステムでは、UNIXオペレーティング・システムのIPC資源が使用され、IPC資源は、表D-1のリストにある調整可能なパラメータで制御されます。

調整可能なパラメータ
調整可能なパラメータの接頭辞	制御内容
SHM	共有メモリーの容量
SEM	セマフォの数
MSG	メッセージ・キューとメッセージのサイズ

これらのパラメータの設定値は、アプリケーションによって異なります。ほとんどのUNIXシステムのデフォルト値は、Oracle Tuxedoアプリケーションを実行するのに十分な大きさには設定されていません。

これらのIPCパラメータはUNIXシステムのバージョンによって異なります。以降の節で説明する内容は一般的なものです。プラットフォームごとの正確なパラメータ名とデフォルトおよびパラメータ値の変更方法については、「Oracle Tuxedo 12c リリース2 (12.2.2)プラットフォーム・データ・シート」を参照してください。パラメータを変更したら、標準の管理ツールを使用してカーネルを再度構築し、オペレーティング・システムを再起動する必要があります。プラットフォームの詳細は、オペレーティング・システムの管理者に問い合わせるか、「システム管理者ガイド」を参照してください。

Oracle Tuxedoアプリケーションを分散化する場合は、そのアプリケーションに参加するすべてのUNIXプラットフォームに必要最低限のIPCリソースを割り当てておく必要があります。

Oracle Tuxedo環境では、共有メモリーが掲示板とワークステーション・リスナー(WSL)プロセスおよびIIOPリスナー(ISL)プロセスの制御表で使用されます。また、アプリケーションで使用される場合もあります。

以下の共有メモリー・パラメータを調整してください。

バイト単位での共有メモリー・セグメントの最大サイズ。割り当てることのできる共有メモリー・セグメントの最大サイズです。ただし、プロセスではSHMMAXサイズのセグメントを複数使用できます。

プロセスあたりの共有メモリー・セグメントの最大数。1つのプロセスで使用できる最大共有メモリー・サイズ(バイト単位)は、SHMMAX * SHMSEGです。6から15までが適正な値です。

システム内の共有メモリー識別子の最大数。Oracle Tuxedoシステムでは、掲示板ごとに共有メモリー識別子が必要です。また、実行しているワークステーション・リスナー(WSL)およびIIOPリスナー(ISL)ごとにも共有メモリー識別子が必要です。

Oracle Tuxedoアプリケーションに参加する各プロセスには、セマフォが必要です。セマフォとは、複数のプロセスが同じ共有メモリー領域に同時にアクセスしないように使用する、ハードウェアまたはソフトウェアのフラグです。あるプロセスが1つの共有メモリー・リソースを制御している場合、そのプロセスがリソースを解放するまで、それ以外のすべてのプロセスはその共有メモリー・リソースにアクセスできません。

Oracle Tuxedoアプリケーションを起動すると、基底のOracle Tuxedoシステムにより、オペレーティング・システムに構成されているセマフォの数が確認されます。十分な数のセマフォが構成されていないと、アプリケーションは起動できません。

次のセマフォ・パラメータを調整してください。

です。MAXACCESSERSはマシン(サーバーとネイティブ・クライアントを含む)上のOracle Tuxedoシステム・プロセスの最大数で、MAXWSCLIENTSはOracle Tuxedoリモート・クライアントの最大数です。これらのパラメータは、どちらもアプリケーションのUBBCONFIGファイルに設定されます。UBBCONFIGの詳細は、「構成ファイルの作成」または『ファイル形式、データ記述、MIBおよびシステム・プロセス・リファレンス』のUBBCONFIG(5)に関する項を参照してください。

セマフォ・セットあたりの最大セマフォ数。SEMMNIとSEMMSLは、その積がSEMMNSになるように設定します。Oracle Tuxedoシステムはセマフォ・セット上でセマフォ操作を行いませんが、できるだけ多くのセマフォをセマフォ・セットに割り当てます。

システム内のundo構造体の数。undo構造体は、掲示板にアクセスできる各プロセスに必要なので、SEMMNUは最低でもSEMMNSと同じ値にします。(UNIXオペレーティング・システムでは、予期せず異常終了したプロセスによって保持されているセマフォを解除するのにundo構造体が使用されます。)

Oracle Tuxedoシステムは、クライアントとサーバーの通信にUNIXシステムのメッセージとメッセージ・キューを使用します。このようなメッセージには、たとえば、サービス・リクエスト、サービス応答、会話型メッセージ、非請求メッセージ、管理メッセージ、トランザクション制御メッセージなどがあります。

サーバーのすべての複数サーバー、単一キュー(MSSQ)セットと個々のサーバーに、リクエストを受信するためのメッセージ・キューがあります。各クライアントには、応答を受信するためのキューがあります。REPLYQパラメータが設定されているサーバーにも、それぞれ応答キューがあります。

カーネル・メッセージ・パラメータを調整することは、アプリケーションを適切にチューニングするために重要です。不適切な値に設定すると、アプリケーションが起動しなかったり、パフォーマンスが著しく低下することがあります。

表D-2に示すように、いくつかのメッセージ・キュー・パラメータを使用して、キュー・スペースの特性を定義できます。

メッセージ・キュー・パラメータ
パラメータ名	指定内容
MSGTQL	カーネルに格納できる未処理のメッセージの総数
MSGMNB	1つのキューに格納できるバイトの最大長
MSGMAX	個々のメッセージの最大サイズ
MSGSEG	任意の時点での未処理のメッセージ・セグメントの総数
MSGSSZ	各セグメントのサイズ

これらのパラメータで指定した制限を超えると、ブロッキング状態が発生します。ただし、MSGMAXは例外です。MSGMNBの75%を超えるメッセージ、またはMSGMAXより大きいメッセージはUNIXファイルに格納されます。受信側にはファイル名を含む小さなメッセージだけが送られます。この動作モードはパフォーマンスを著しく低下させるので、使用しないことをお薦めします。

メッセージの送信時にすべてのプロセスがブロックされると、アプリケーション・デッドロックが発生します。たとえば、クライアントからのリクエストでメッセージ領域がいっぱいになると、応答を戻すサーバーがブロックされます。そのため、メッセージを読み取れるサーバーがなくなり、デッドロックが発生します。タイムアウトによってデッドロックを解除できる場合もあります。ただし、本来行われるべき処理は何も行われていません。

特に問題となるのは、TPNOREPLYフラグが指定されているリクエストを送信するクライアントです。その場合、メッセージのサイズによって異なりますが、クライアントのキューまたはシステムのメッセージ領域にメッセージが蓄積されてしまいます。このようなアプリケーションには、未処理のメッセージ数をそのアプリケーションが制限できるようなフロー制御ルーチンが必要です。

つまり、クライアントやサーバーが送信操作(サービスのリクエストまたは応答の送信)でブロックされている場合、潜在的に問題が発生する可能性があります。ただし、システム内のほかのキューにメッセージを受け付けられる領域があれば、1つのサーバー・リクエスト・キューが常にいっぱいになっている状態でも、通常は問題は発生しません。

キューのブロッキング状態は送信側と受信側の両方で、パフォーマンスに問題を引き起こします。ブロックされているプロセスをウェイクアップする際、UNIXオペレーティング・システムは1つのプロセスしか処理できない場合でも、特定のイベントによりブロックされているすべてのプロセスをウェイクアップします。処理されないプロセスは再度スリープ状態に戻ります。このプロセス・スケジューリングのオーバーヘッドは大きくなる場合があります。

たとえば、複数のサーバー(MSSQ)が存在する空のサーバー・リクエスト・キューでは、メッセージが受信されると、そのキューにあるすべてのアイドル(ブロックされている)サーバーがウェイクアップします。サーバー・リクエスト・キューがいっぱいになっている場合は、サーバーがそれぞれのリクエストを読み込み、システムはブロックされているすべてのクライアントをウェイクアップします。メッセージのサイズに応じて、ゼロ以上のクライアントがキューにメッセージを置きます。ほかのクライアントは再度スリープ状態に戻ります。システム内には数百ものクライアントが存在する場合もあるので、サービス・リクエストを処理するたびにすべてのクライアントをウェイクアップするのはパフォーマンスを大幅に低下させることになります。

適切にチューニングされているシステムでは、キューがいっぱいになることはほとんどありません。メッセージ・フローの変化に対応できるだけの十分な余裕をキューに残す必要があります。お薦めできるこれといった設定はありません。調整はアプリケーションによって大きく異なります。UNIXシステムのipcs(1)コマンドを使用してキューのスナップショットを取ると、キューがいっぱいかどうかを確認できます。リクエストの送信時に、TPNOBLOCKフラグを設定することも1つの方法です。これを行うと、クライアントはいつキューがいっぱいになるかがわかり、若干ペースを落とすことができます。リクエスト・キューがいっぱいになっているサーバーのスケジューリングの優先度を上げることも有効な方法です。

以下のメッセージ・パラメータを調整してください。

一意のメッセージ・キュー識別子の数。マシン上のOracle Tuxedoアプリケーションに参加している各プロセスには、通常、少なくとも1つのメッセージ・キューが必要です。MSSQセットを使用する場合はこの数は小さくなります - つまり、複数のサーバー・プロセスが1つのキューを共有します。トランザクション処理では、トランザクション・マネージャ・サーバー(TMS)プロセスのサーバー・グループごとに1つのキューを割り当てます。したがって、MSGMNIの最低限の必要値は、次の計算式から求められます。

バイト単位でのメッセージ・キューの最大長。キューに格納されているすべてのメッセージの合計バイト数より大きくなければなりません。MSGMNBの最小値はMSGMAXの値です。MSGMNBの75%より長いメッセージは、メッセージ・キューではなくファイルに格納されます。その場合、パフォーマンスが著しく低下するので、このような状態は避けるようにします。

メッセージ・セグメントを管理するために使用される制御マップ内のエントリ数。MSGMAPの値は、メッセージ・セグメントの数(MSGSEGで指定された値)と同じでなければなりません。

バイト単位でのメッセージ・セグメントのサイズ。メッセージは複数のセグメントで構成されます。MSGSSZの値は、通常送信されるメッセージのサイズ(Oracle Tuxedoシステム・ヘッダーも含む)とMSGSSZの倍数が等しくなるように設定します。このようにメッセージをいくつかのセグメントに分割すると、領域が無駄になりません。

Oracle Tuxedoシステムでは、そのほかにも設定値を大きくする必要があるUNIXシステムの調整可能なパラメータがあります。これらのパラメータはアプリケーションに大きく依存しており、すべてのアプリケーションに適用されるわけではありません。各プラットフォームのデフォルトとその変更手順については、「Oracle Tuxedo 12c リリース2 (12.2.2)プラットフォーム・データ・シート」を参照してください。

最大ファイル・サイズ。ULIMITは、Oracle Tuxedoシステムをインストールし、サーバーを構築できるだけの値に設定する必要があります。4MBに設定することをお薦めします。

スーパーユーザー以外のユーザーが使用できる最大プロセス数。Oracle Tuxedoシステムのプロセス、つまりサーバーと管理プロセスは、アプリケーションのUBBCONFIGファイルに設定されたUIDで実行します。MAXUPは、これらのプロセスすべてが実行できる大きさの値でなければなりません。

割り当てられる領域表エントリの数。ほとんどのプロセスには、テキスト、データ、スタックの3種類の領域があります。アタッチされる共有メモリー・セグメントと共有ライブラリ(テキストとデータを含む)にも領域が必要です。ただし、「共有テキスト」プログラムのテキストのための領域表エントリは、そのプログラムを実行するすべてのプロセスで共有されます。1つまたは複数のプロセスにアタッチされる共有メモリー・セグメントでは、それぞれ別の領域表エントリが使用されます。

トランスポート層インタフェース(TLI)がプッシュ(push)できるSTREAMSモジュールの最大数。通常のデフォルト値は16です。少なくとも256以上に設定することをお薦めします。