WebSphere Application Server for i5/OS, Version 6.1   
             オペレーティング・システム: i5/OS

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

トレース・サービスを使用する EJB キャッシュのチューニング

このタスクについて

Enterprise JavaBeans (EJB) キャッシュのサイズは、アプリケーション・サーバーのパフォーマンスに影響を及ぼすことがあります。 EJB コンテナーを最適パフォーマンス・レベルにチューニングする手順の 1 つに、EJB キャッシュの微調整があります。 以下で、診断トレース・サービスを使用してキャッシュの最善サイズを決める方法を説明します。

プロシージャー

  1. EJB キャッシュ・トレースを使用可能にします。 トレース・サービスの操作を知るには、 トレースによる処理 を参照してください。 トレース・サービスの設定の詳細については、 を参照してください。
    次のトレース・ストリングを使用するようにトレースをセットアップします。

    com.ibm.ejs.util.cache.BackgroundLruEvictionStrategy=all=enabled:com.ibm.ejs.util.cache.CacheElementEnumerator=all=enabled

    最大ファイル・サイズ」を 200 MB 以上に設定します。 デフォルト値の 20 MB のままにしておくと、20 MB のトレース・ログがいっぱいになり、トレースが折り返されてデータが失われることがあります。

    ヒストリー・ファイルの最大数」を 5 に設定します。 ファイル数は 5 つで充分であると考えられますが、これら 5 つのファイルがすべていっぱいになり、トレースの折り返しが発生する場合は、この値を増やしてください。

  2. サーバーを停止し、既存のログを削除してから、サーバーを始動します。
  3. 標準的な手順を実行してキャッシュ・トレース・データを収集します。 トレースを有効にした標準的な手順を実行することで、次のステップで分析する EJB キャッシュ・トレース・データを取得します。
  4. トレース出力を表示して分析します。
    1. トレース・ログを開きます。 以下のトレース・ストリングのいずれか、または両方があるかどうかを確認します。

      BackgroundLru 3  EJB Cache: Sweep (1,40) - Cache limit not reached : 489/2053
      BackgroundLru >  EJB Cache: Sweep (16,40) - Cache limit exceeded : 3997/2053 Entry

      Cache limit」というワードを含んだトレース・ストリング内に、比率があります。 例えば、3997/2053 など。 最初の数は現在 EJB キャッシュ内にある エンタープライズ Bean の数 (容量> という) です。 2 番目の数は EJB キャッシュ設定値です (詳細については、後のステップで解説します)。 分析の際には、この比率、特に容量を使用します。

      また、「Cache limit not reached 」および「Cache limit exceeded 」というステートメントを探してください。
      Cache limit not reached
      キャッシュの現在のサイズが適切か、それ以上です。 適切なサイズを越えている場合はメモリーを浪費しているので、以下に説明する方法でキャッシュ・サイズを適当な値まで削減してください。
      Cache limit exceeded
      現在使用されている Bean の数が指定した容量を越えており、これはキャッシュが正しくチューニングされていないことを示しています。 EJB キャッシュ設定値はハード制限ではないので、容量がこの設定値を超えることがあります。 この制限に達しても、EJB コンテナーはキャッシュへの Bean の追加を停止しません。 これは、キャッシュがフルになったとき、Bean に対する要求が実現されなかったり、少なくともキャッシュ・サイズが制限以下になるまで遅延するということを意味します。 つまり、キャッシュ制限を超えることがあっても、EJB コンテナーはキャッシュをクリーンアップして EJB キャッシュ・サイズ未満に保持することを試みます。
      キャッシュ制限を超えた場合、トレース・ポイントが次のようになる場合があります。

      BackgroundLru <  EJB Cache: Sweep (64,38) - Evicted = 50 : 3589/2053 Exit

      Evicted = というストリングに注意してください。 このストリングが表示される場合、オプション A または B のキャッシングが設定されたステートフル・セッション Bean またはエンティティー Bean を使用していることになります。 オブジェクトが除去されたということは、選択したキャッシング・オプションのメリットを十分に利用していないことになります。 まず、EJB キャッシュ・サイズを増やすことを試みてください。 アプリケーションを引き続き実行するとさらに多くのオブジェクトが除去される場合、 このアプリケーションは EJB キャッシュ・スイープ間との間でキャッシュが保有できる量を超える Bean に アクセスしたり新規 Bean を作成したりしており、既存の Bean を再利用していいない ことを意味します。 この時点で、エンティティー Bean にオプション C キャッシングを使用すること、あるいは アプリケーションがもう必要のなくなったステートフル・セッション Bean を除去していないかどうかを確認することを検討します。
      注: オプション C キャッシングで構成されたエンティティー Bean は、トランザクションの間のみキャッシュ内にありますが、 トランザクションを通じてキャッシュ内に保持することを求められます。 したがって、これらのエンティティー Bean はキャッシュ・スイープ中に除去されることはありませんが、 トランザクションが完了するとキャッシュから除去されます。 さらに、ステートレス・セッション Bean、またはオプション C キャッシングが設定されたエンティティー Bean (あるいはその両方) を使用している場合、EJB キャッシュのクリーンアップ間隔 をより大きな値に増やしておいた方が良い場合があります。 クリーンアップ間隔は、EJB キャッシュ設定 に記載されている方法で設定できます。 ステートレス・セッション Bean は EJB キャッシュ内に存在しません。 オプション C キャッシングを使用するエンティティー Bean はキャッシング (LRU) 戦略によって除去されることはないので、 実際はさほど頻繁にスイープする必要はありません。 ステートレス・セッション Bean かオプション C キャッシングのみを使用している場合、上記のトレース例に "Evicted = 0" だけが表示されるはずです。
    2. トレース・ログを分析します。 Cache limit exceeded というトレース・ストリングを探します。
      • このストリングは複数見つかる場合があります。 その場合はそれらすべてを調べて、EJB キャッシュ内の Bean の最大容量の値を見つけます。 EJB キャッシュ・サイズを、この容量値のほぼ 110% に再設定します。 EJB キャッシュ・サイズの設定法については、後のステップで説明します。
      • このトレース・ストリングが 1 つもない場合もあります。 これは、EJB キャッシュの容量 (最終目標) を越えていないことを意味しますが、 初期分析中に最終目標が見えていないということは、キャッシュが大きすぎて不要なメモリーを使用している可能性もあります。 この場合、キャッシュ制限を超えるまでキャッシュ・サイズを減らしてから、最適な値まで増やすことで、キャッシュを調整する必要があります。 EJB キャッシュ・サイズの設定法については、後のステップで説明します。
      ここでの最終目標は、リソースを浪費しないが、超過することもない値にキャッシュ制限を設定することです。 セットアップが適切な場合、トレース中に表示されるメッセージは「Cache limit not reached 」のみであり、容量の値は EJB キャッシュ設定値の 100% に近づきつつそれを超えない比率になります。
      注: キャッシュ・サイズはデフォルト値の 2053 未満には設定変更しないことをお勧めします。
  5. 分析に基づいてキャッシュ設定値を変更してください。 この方法について詳しくは、EJB キャッシュ設定 を参照してください。
  6. サーバーを停止し、すべてのログを削除し、サーバーを再始動します。
  7. 設定値に納得するまで、上記のステップを繰り返してください。
  8. EJB キャッシュ・トレースを使用不可にします。 キャッシュを適切にチューニングすると、トレースを除去し、 古いログを削除して、サーバーを再始動できます。

次の作業

分析の結果、EJB コンテナーの観点から EJB キャッシュを最適に設定することは可能ですが、その値は WebSphere Application Server の観点からすると最適ではない可能性があります。 キャッシュ・サイズが大きい方がヒット数は高くなり、EJB キャッシュのパフォーマンスは向上しますが、メモリー使用量は増加します。 キャッシュに使用されるメモリーはその製品の他の領域では使用できないので、全体的なパフォーマンスが低下する可能性があります。 メモリーが豊富にあるシステムでは、パフォーマンスの低下は問題にならず、EJB キャッシュを適切にチューニングすることで全体的なパフォーマンスが向上します。 ただし、キャッシュを構成するときには、システムのパフォーマンスと EJB キャッシュのパフォーマンスを対比させて考慮する必要があります。




関連タスク
トレースによる処理
関連資料
EJB キャッシュ設定
タスク・トピック    

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

最終更新: Jan 21, 2008 5:46:14 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.base.iseries.doc/info/iseries/ae/tejb_tunecash.html