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

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

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

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

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

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

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

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パラメータが設定されているサーバーにも、それぞれ応答キューがあります。

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

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

これらのパラメータで指定した制限を超えると、ブロッキング状態が発生します。ただし、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 11gリリース1(11.1.1.2.0)プラットフォーム・データ・シート」を参照してください。

ULIMIT

NOFILES

MAXUP

NPROC

NREGION

NUMTIM

NUMTRW