![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
オブジェクト・リクエスト・ブローカーのチューニング・ガイドライン
Object Request Broker (ORB) がワークロード内で使用されているときにはいつでも、この文書内のガイドラインを使用してください。
ORB は、エンタープライズ Bean がリモート・インターフェースを介してアクセスされたときはいつでも使用されています。 CPU 使用量が特に高い、あるいは低いということが起こった場合は、以下のパラメーターのいずれかの値に問題があるかもしれません。 すべてのアプリケーション・デプロイメントに対するコアのチューニング・パラメーターを調べます。
スレッド・プール調整
サイズ
ご使用のワークロードに従って ORB スレッド・プールのサイズを調整します。 中断中のスレッドには、処理の準備ができた作業がないので、避けてください。 スレッドに、処理の準備ができた作業がない場合は、CPU 時間が Object.wait メソッドを呼び出すことによって、コンテキスト・スイッチを実行して消費されます。 スレッド・プール・サイズを調整して、スレッドの待機時間を短くし、アイドル状態が長すぎるために破棄されるのを防止してください。
スレッド・プール・サイズは、ご使用のワークロードおよびシステムによって決まります。 標準の構成では、アプリケーションはプロセッサーごとに 10 またはそれ以下のスレッドを必要とします。
しかし、ご使用のアプリケーションが、データベース・システムへの要求などの非常に遅いバックエンド要求を実行している場合は、サーバー・スレッドはバックエンド要求の完了まで待機することをブロックします。 バックエンド要求を使用している場合は、CPU 使用はかなり低くなります。 この場合、ロードの増加によって CPU 使用またはスループットは増加しません。 スレッド・ダンプは、ほとんどすべてのスレッドが、バックエンド・リソースへの呼び出し内にあることを示しています。 この場合、スループットが改善され、スレッド・ダンプがスレッドがバックエンド・コール以外のほかの領域のランタイム内にあることを表示するまで、プロセッサーごとのスレッドを増加させることを考慮します。 ご使用のバックエンド・リソースが正しく調整されている場合のみ、スレッドの数を調整すべきです。
最大スレッド・サイズを超えたスレッド割り振りを許可 パラメーターはまた、スレッド・プール・サイズにも影響を与えます。しかし、バックエンド・システムを含まない他の作業の処理をせずにバックエンド・システムを待機するすべてのランタイム・スレッドをブロックする原因となるので、バックエンドが長時間停止しない限りこのパラメーターを使用しないでください。
管理コンソール内で、スレッド・プール・サイズの設定を調整することができます。 「サーバー」> 「サーバー・タイプ」>「アプリケーション・サーバー」> 「server_name」 >「コンテナー・サービス」>「ORB サービス」>「スレッド・プール」の順でクリックします。スレッドの最小数および最大数を調整することができます。
スレッド・プール・タイムアウト
ORB を介した各インバウンド要求とアウトバウンド要求には、ORB スレッド・プールのスレッドが必要です。負荷の大きいシナリオまたは ORB が深いネストを要求するシナリオでは、Java™ 仮想マシン (JVM) が、ORB スレッド・プールのすべてのスレッドを保有して、要求の送信を試みている可能性があります。一方で、これらの要求を処理するリモート JVM ORB が、ORB スレッド・プールのすべてのスレッドを保有して、要求の送信を試みている可能性があります。その結果、処理は進行しません。スレッドは ORB スレッド・プールに解放されず、ORB は要求を処理できません。結果的に、デッドロックが発生する場合があります。管理コンソールを使用して、ORB com.ibm.websphere.orb.threadPoolTimeout カスタム・プロパティーを介してこの動作を調整できます。 詳しくは、「オブジェクト・リクエスト・ブローカーのカスタム・プロパティー」に関する 資料を参照してください。
フラグメント・サイズ
ORB は、メッセージをフラグメントに分割し 、ORB 接続を介して送信します。com.ibm.CORBA.FragmentSize パラメーターを使用して、 このフラグメントを構成できます。
- 管理コンソールで、ORB プロパティー・ページの ORB トレースを有効化します。
- ログ・ページおよびトレース・ページから ORBRas トレースを有効化します。
- トレースは多量のデータを生成することがあるため、トレース・ファイル・サイズを増やします。
- この場合は、サーバーを再始動して、 測定している反復ケースを少なくとも 1 回 (可能ならば複数回) 実行します。
- 追跡可能なファイルを参照して、Fragment to follow: Yes を検索します。
このメッセージは、ORB がフラグメントを送信したが、 全メッセージが到達する前に送信されるフラグメントが 少なくとも 1 つ残っているということを示します。 Fragment to follow: No の値は、 特定のフラグメントが全メッセージの最後にあることを示しています。メッセージが 1 つのフラグメントに完全に収まる場合には、このフラグメ ントは最初になる場合もあります。
Fragment to follow: Yes が記述されている箇所に進むと、 次の例のようなブロックがあります。
Fragment to follow: Yes Message size: 4988 (0x137C) -- Request ID: 1411
この例は、フラグメントのデータ量が 4988 バイトで、 要求 ID が 1411 であることを示します。「Request ID: 1411」と 記述されている個所をすべて検索する場合、その特定メッセージの送信で使用されるフラグメントの数がわかります。関連のあるメッセージ・サイズをすべて加算すると 、ORB を使用して送信されるメッセージ」の合計サイズになります。
- com.ibm.CORBA.FragmentSize ORB カスタム・プロパティーを設定することによって、フラグメント・サイズを構成できます。
インターセプター
インターセプターは、ORB が要求を実行する前にコンテキストをセットアップすることができる ORB の拡張機能です。 例えば、コンテキストはインポートするトランザクションまたはアクティビティー・セッションを含むことができます。 クライアントがトランザクションを作成し、次にトランザクション・コンテキストをサーバーにフローした場合、サーバーがインターセプターを介してサーバー要求上にトランザクション・コンテキストをインポートします。
ほとんどのクライアントはトランザクションまたはアクティビティー・セッションを開始しないので、ほとんどのシステムにとって、必要ではないインターセプターを除去することは利益があります。
インターセプターを除去するには、 手動で server.xml ファイルを編集し、ORB セクションから必要ではないインターセプター行を除去します。
接続キャッシュの調整
アプリケーション・サーバーのワークロードおよび、スループットまたは応答時間の要件によっては、 ORB の接続キャッシュのサイズを調整する必要があります。 接続キャッシュ内の各エントリーは、それぞれ個別の TCP/IP ソケット・エンドポイントを表すオブジェクトであり、 ホスト名または TCP/IP アドレス、および、 ORB がリモート・ターゲット・エンドポイントに GIOP 要求または GIOP 応答を送信するのに使用する ポート番号によって識別されます。接続キャッシュの目的は、 ORB 接続オブジェクトを後続の要求または応答で再利用して、 接続の確立に必要な時間をできるだけ短くすることです。 (要求とそれに対応する応答には、同じ TCP/IP ソケットが使用されます)。
各アプリケーション・サーバーでは、接続キャッシュ内のエントリー数は、 並行する ORB 接続の数と直接関係があります。これらの接続は、 リモート・クライアントからのインバウンド要求と、アプリケーション・サーバーによる アウトバウンド要求の両方で構成されています。サーバー・サイドの ORB は、 接続要求を受け取ると、キャッシュ内のエントリーから既存の接続を使用するか、 新規接続を確立してその接続のエントリーをキャッシュに追加します。
ORB の最大接続キャッシュ・プロパティーおよび最小接続キャッシュ・プロパティーは、 任意の時点における接続キャッシュ内のエントリーの最大数および最小数の制御に使用されます。 エントリー数が、最大接続キャッシュ・プロパティーで指定した値に達し、 新しい接続が必要になった場合、ORB は要求された接続を作成して、 キャッシュにエントリーを追加し、最大 5 つまでの非アクティブ接続エントリーを検索して、 キャッシュから除去します。 新規接続は、非アクティブなエントリーが除去される前に追加されるため、 キャッシュ・エントリーの数が、最大接続キャッシュ・プロパティーで指定した値を 一時的に超える可能性があります。
ORB 接続は、TCP/IP ソケット・ストリームが使用されておらず、 その接続上で作成された要求に対して保留になっている GIOP 応答が存在しない場合に、 非アクティブと見なされます。アプリケーション・ワークロードが減少すると、 ORB は接続を終了し、この接続のエントリーをキャッシュから除去します。 ORB は、残りのエントリー数が最大接続キャッシュ・プロパティーで指定した値以下になるまで、 キャッシュからのエントリーの除去を続けます。 キャッシュ・エントリーの数は、最小接続キャッシュ・プロパティーで指定した値を下回ることはありません。 このプロパティーには、最大接続キャッシュ・プロパティーで指定した値より、 5 つ以上少ない接続数を指定する必要があります。
クライアント・サイド ORB での接続キャッシュの調整は、 クライアント・サイドでは少数の接続しか行われないため、通常は必要ありません。
JNI リーダー・スレッド
デフォルトでは、ORB は、受信する個々のインバウンド接続要求の処理に Java スレッドを使用します。 並行する要求の数が増えると、多数のリーダー・スレッドが消費する ストレージの量が増え、リソースに制約のある環境ではそれがボトルネックになる場合があります。 最終的に、並行する要求数がシステムの使用可能なリソースを超えると、作成される Java スレッドの数がメモリー不足例外の原因になる場合があります。
この潜在的な問題に対処するには、JNI リーダー・スレッドを使用するように ORB を構成します。 これにより、限られた数のリーダー・スレッドが、Java スレッドではなくネイティブの OS スレッドにより実装され、ORB を初期化する間に作成されます。 JNI リーダー・スレッドは、ネイティブ OS の TCP/IP 非同期メカニズムに依存しています。 このメカニズムでは、1 つのネイティブ OS スレッドが、複数のソケットからの入出力イベントを、 同時に処理することができます。 ORB は、JNI リーダー・スレッドの使用を管理し、 ラウンドロビン・アルゴリズムを使用して、 使用可能なスレッドの 1 つを接続要求の処理に割り当てます。 通常、JNI リーダー・スレッドの構成は、Java スレッドを使用するとアプリケーション環境でメモリーが大量に消費される場合でなければ、行う必要はありません。
- 一定数のスレッドが割り振られるため、メモリーの使用量が抑えられます。 これは、常時大量のクライアント要求ワークロードがある環境では、 かなりのメリットになります。
- Java スレッドを動的に作成および破棄するための時間が不要になります。 これは、ORB を初期化する間に一定数の JNI スレッドが作成され、割り振られるためです。
- JNI スレッドはそれぞれ、最大で 1024 のソケット接続を処理でき、 ネイティブ OS の非同期入出力メカニズムと直接対話します。 このメカニズムによって、ネットワークの入出力処理のパフォーマンスが向上します。