WebSphere Application Server Network Deployment, Version 6.0.x   
             オペレーティング・システム: AIX , HP-UX, Linux, Solaris, Windows

             目次と検索結果のパーソナライズ化

オブジェクト・リクエスト・ブローカーのチューニング・ガイドライン

Object Request Broker (ORB) がワークロード内で使用されているときにはいつでも、この文書内のガイドラインを使用してください。

ORB は、エンタープライズ Bean がリモート・インターフェースを介してアクセスされたときはいつでも使用されています。 CPU 使用量が特に高い、あるいは低いということが起こった場合は、以下のパラメーターのいずれかの値に問題があるかもしれません。 すべてのアプリケーション・デプロイメントに対するコアのチューニング・パラメーターを調べます。

スレッド・プール調整

サイズ

ご使用のワークロードに従って ORB スレッド・プールのサイズを調整します。 中断中のスレッドには、処理の準備ができた作業がないので、避けてください。 スレッドに、処理の準備ができた作業がない場合は、CPU 時間が Object.wait メソッドを呼び出すことによって、コンテキスト・スイッチを実行して消費されます。 スレッド・プール・サイズを調整して、スレッドの待機時間を短くし、アイドル状態が長すぎるために破棄されるのを防止してください。

スレッド・プール・サイズは、ご使用のワークロードおよびシステムによって決まります。 標準の構成では、アプリケーションはプロセッサーごとに 10 またはそれ以下のスレッドを必要とします。

しかし、ご使用のアプリケーションが、データベース・システムへの要求などの非常に遅いバックエンド要求を実行している場合は、サーバー・スレッドはバックエンド要求の完了まで待機することをブロックします。 バックエンド要求を使用している場合は、CPU 使用はかなり低くなります。 この場合、ロードの増加によって CPU 使用またはスループットは増加しません。 スレッド・ダンプは、ほとんどすべてのスレッドが、バックエンド・リソースへの呼び出し内にあることを示しています。 この場合、スループットが改善され、スレッド・ダンプがスレッドがバックエンド・コール以外のほかの領域のランタイム内にあることを表示するまで、プロセッサーごとのスレッドを増加させることを考慮します。 ご使用のバックエンド・リソースが正しく調整されている場合のみ、スレッドの数を調整すべきです。

最大スレッド・サイズを超えたスレッド割り振りを許可 パラメーターはまた、スレッド・プール・サイズにも影響を与えます。しかし、バックエンド・システムを含まない他の作業の処理をせずにバックエンド・システムを待機するすべてのランタイム・スレッドをブロックする原因となるので、バックエンドが長時間停止しない限りこのパラメーターを使用しないでください。

管理コンソール内で、スレッド・プール・サイズの設定を調整することができます。 「サーバー」 > 「アプリケーション・サーバー>server_name」> 「コンテナー・サービス」> 「ORB サービス」 > 「スレッド・プール」とクリックします。 スレッドの最小数および最大数を調整することができます。 詳しくは、スレッド・プール設定 を参照してください。

参照による受け渡し

ORB がパラメーターを渡す方法を指定します。これが使用可能になっていると、 ORB は、値によるパラメーターの代わりに参照によるパラメーターを渡して、オブジェクト・コピーが行われないようにします。 参照による受け渡しオプションが有効になっていない場合は、 パラメーター・オブジェクトそのものではなく、パラメーターのコピーが渡されます。 この場合、ORB が最初に各パラメーター・オブジェクトのコピーを作成する必要があるため、 コストがかかる可能性があります。

このオプションは、Enterprise JavaBeans (EJB) クライアントと EJB が同一のクラス・ローダーにある場合にのみ使用することができます。 つまり、EJB クライアントと EJB が同一の EAR ファイル内にデプロイされる必要があります。

Enterprise JavaBeans (EJB) クライアントとサーバーが同じ WebSphere Application Server インスタンスにインストールされていて、 かつ、クライアントとサーバーがリモート・インターフェースを使用している場合は、 参照による受け渡しオプションを使用可能にすることで、パフォーマンスを最高 50% 向上させることができます。 参照による受け渡しオプションによってパフォーマンスが改善されるのは、非プリミティブ・オブジェクト・タイプが パラメーターとして渡される場合だけです。 したがって、int および float は、呼び出しモデルに関係なく常にコピーされます。

重要: このプロパティーを使用可能にすると、予期しない振る舞いをする場合があるため、注意してください。 呼び出し先によってオブジェクト参照が変更されると、 呼び出し元のオブジェクトも同じオブジェクトであるため変更されます。

コマンド行スクリプトを使用する場合、このシステム・プロパティーのフルネームは com.ibm.CORBA.iiop.noLocalCopies です。

データ型 ブール
デフォルト 使用不可 (false)

リモート・インターフェースでエンタープライズ Bean にこのオプションを使用すると、Enterprise JavaBeans (EJB) 仕様バージョン 2.0 に違反することになります (セクション 5.4 を参照)。Enterprise JavaBeans (EJB) メソッドまたは EJB ホーム・メソッドへ渡されるオブジェクト参照はコピーされず、 破壊を受けやすくなる可能性があります。

次の例を検討してみましょう。
Iterator iterator = collection.iterator();
MyPrimaryKey pk = new MyPrimaryKey();
while (iterator.hasNext()) {
   pk.id = (String) iterator.next();
   MyEJB myEJB = myEJBHome.findByPrimaryKey(pk);
}

この例では、同じ MyPrimaryKey オブジェクトへの参照が、毎回異なる ID 値で WebSphere Application Server に渡されます。 「参照による受け渡し」を使用可能にしてこのコードを実行すると 、アプリケーション・サーバー内に問題が生じます。これは、複数のエンタープライズ Bean が同じ MyPrimaryKey オブジェクトを参照するためです。 この問題を回避するには、「参照による受け渡し」オプションを使用可能にするときに、 com.ibm.websphere.ejbcontainer.allowPrimaryKeyMutation システム・プロパティーを true に設定します。 「参照による受け渡し」オプションを true に設定すると、EJB コンテナーが PrimaryKey オブジェクトのローカル・コピーを作成します。 ただし、その結果、「参照による受け渡し」オプションを設定することによるパフォーマンス上の利点が少し失われます。

一般に、オブジェクト参照をパラメーターとしてエンタープライズ Bean メソッドまたは EJB ホーム・メソッドに渡すアプリケーション・コードは、念入りに調べて、 そのオブジェクト参照を渡すことにより、データの保全性が失われるなどの問題が生じないかどうかを確認する必要があります。

ご使用のコードを確認後、com.ibm.CORBA.iiop.noLocalCopies システム・プロパティーを true に設定して、 「参照による受け渡し」オプションを使用可能にすることができます。 また、管理コンソールでも「参照による受け渡し」オプションを使用可能にすることができます。 「サーバー」>「アプリケーション・サーバー」>「server_name」>「コンテナー・サービス 」>「ORB サービス」とクリックし、「参照による受け渡し」を選択します。

フラグメント・サイズ

ORB は、メッセージをフラグメントに分割し 、ORB 接続を介して送信します。com.ibm.CORBA.FragmentSize パラメーターを使用して、 このフラグメントを構成できます。

ORB を介して送信するメッセージのサイズと必要なフラグメント数を決定し、変更するには、以下のステップを実行します。
  1. 管理コンソールで、ORB プロパティー・ページの ORB トレースを有効化します。 詳しくは、オブジェクト・リクエスト・ブローカー・サービス設定 を参照してください。
  2. ログ・ページおよびトレース・ページから ORBRas トレースを有効化します。
  3. トレースは多量のデータを生成することがあるため、トレース・ファイル・サイズを増やします。
  4. この場合は、サーバーを再始動して、 測定している反復ケースを少なくとも 1 回 (可能ならば複数回) 実行します。
  5. 追跡可能なファイルを参照して、Fragment to follow: Yes を検索します。

    このメッセージは、ORB がフラグメントを送信したが、 すべてのメッセージが到達する前に送信されるフラグメントが 少なくとも 1 つ残っているということを示します。 Fragment to follow: No の値は、 特定のフラグメントが全メッセージの最後にあることを示しています。メッセージが 1 つのフラグメントに完全に収まる場合には、このフラグメ ントは最初になる場合もあります。

    Fragment to follow: Yes が記述されている箇所に進むと、 次の例のようなブロックがあります。

    Fragment to follow: はい
    Message size: 4988 (0x137C)
    --  
    Request ID: 1411

    この例は、フラグメントのデータ量が 4988 バイトで、 要求 ID が 1411 であることを示します。「Request ID: 1411」と 記述されている個所をすべて検索する場合、その特定メッセージの送信で使用されるフラグメントの数がわかります。関連のあるメッセージ・サイズをすべて加算すると 、ORB を使用して送信されるメッセージ」の合計サイズになります。

  6. com.ibm.CORBA.FragmentSize プロパティーを設定することによって、フラグメント・サイズを構成することができます。 詳しくは、 オブジェクト・リクエスト・ブローカーのカスタム・プロパティー を参照してください。
インターセプター

インターセプターは、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 スレッドの数が、 並行する要求数がシステムの使用可能なリソースを超えると、 メモリー不足例外の原因になる場合があります。

この潜在的な問題に対処するには、ORB を、JNI リーダー・スレッドを使用するように構成します。 すると、一定数のリーダー・スレッドが、Java スレッドではなくネイティブの OS スレッドによりインプリメントされ、 ORB の初期設定時に作成されます。 JNI リーダー・スレッドは、ネイティブ OS の TCP/IP 非同期メカニズムに依存しています。 このメカニズムでは、1 つのネイティブ OS スレッドが、複数のソケットからの入出力イベントを、 同時に処理することができます。 ORB は、JNI リーダー・スレッドの使用を管理し、 ラウンドロビン・アルゴリズムを使用して、 使用可能なスレッドの 1 つを接続要求の処理に割り当てます。 通常、JNI リーダー・スレッドの構成は、 Java スレッドを使用するとアプリケーション環境でメモリーが大量に消費される場合でなければ、 行う必要はありません。

ORB に割り当てる JNI リーダー・スレッドの数は、さまざまな要因によって決まり、 環境ごとに、また使用できるシステム・リソースやワークロードの要件によっても、 大幅に異なります。JNI スレッドを使用する場合の利点としては、 次のようなことが考えられます。
  • 一定数のスレッドが割り振られるため、メモリーの使用量が抑えられます。 これは、常時大量のクライアント要求ワークロードがある環境では、 かなりのメリットになります。
  • Java スレッドを動的に作成および破棄するための時間が不要になります。 これは、ORB の初期設定時に一定数の JNI スレッドが作成され、割り振られるためです。
  • JNI スレッドはそれぞれ、最大で 1024 のソケット接続を処理でき、 ネイティブ OS の非同期入出力メカニズムと直接対話します。 このメカニズムによって、ネットワークの入出力処理のパフォーマンスが向上します。
注意:
JSSE2 は、JNI リーダー・スレッドが必要とするファイル記述子を提供しないので、 デフォルトの IBMJSSE2 SSL セキュリティー・プロバイダー設定では、JNI リーダー・スレッドを使用できません。これらの両方の 設定を使用しようとすると、サーバーは始動せず、com.ibm.jsse2.c クラス の ClassCast 例外がログに記録されます。



関連タスク
アプリケーション・サービス提供環境のチューニング
関連資料
オブジェクト・リクエスト・ブローカー・サービス設定
参照トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 10:13:28 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/rorb_tims.html