Oracle Tuxedo システムのインストール

UNIX システムでの IPC リソースのコンフィグレーション

以下の節では、UNIX システムでのプロセス間通信 (IPC) パラメータについて説明し、そのコンフィグレーション方法のガイドラインを示します。

IPC リソースを制御するパラメータ セット

UNIX 上の Oracle Tuxedo システムでは、UNIX オペレーティング システムの IPC 資源が使用されます。IPC 資源は、以下に示す 3 種類の調整可能なパラメータ セットで制御されます。

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

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

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

共有メモリ

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

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

SHMMAX

SHMSEG

SHMMNI

SHMMIN

セマフォ

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

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

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

SEMMNS

SEMMNI

SEMMSL

SEMMAP

SEMMNU

SEMUME

メッセージ キューとメッセージ

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

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

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

次の表に示すように、いくつかのメッセージ キュー パラメータを使用して、キュー空間の特性を定義することができます。

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

アプリケーション デッドロックとは

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

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

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

ブロッキング状態がパフォーマンスに及ぼす影響

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

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

調整可能なメッセージ パラメータ

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

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

MSGMNI

MSGMAX

MSGMNB

MSGMAP

MSGSSZ

MSGSEG

MSGTQL

そのほかの調整可能なカーネル パラメータ

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

ULIMIT

NOFILES

MAXUP

NPROC

NREGION

NUMTIM

NUMTRW