トレース・サービスによる 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

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

   Maximum Number of Historical Files を 5に設定します。 5 つのファイルで十分ですが、5 つのファイルがすべていっぱいになり、トレースの折り返しが発生することがわかった場合は、この値を増やしてください。

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

      BackgroundLru 3 EJB キャッシュ: スイープ (1,40)-キャッシュ制限に達していません: 489/2053
      BackgroundLru > EJB キャッシュ: スイープ (16,40)-キャッシュ制限を超えました: 3997/2053 エントリー

      「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 キャッシュ: Sweep (64,38)-Evicted = 50: 3589/2053 出口

      Evicted = というストリングに注意してください。 このストリングが表示される場合、オプション A または B のキャッシングが設定されたステートフル・セッション Bean またはエンティティー Bean を使用していることになります。 オブジェクトが除去されたということは、選択したキャッシング・オプションのメリットを十分に利用していないことを意味します。 まず、EJB キャッシュ・サイズを増やすことを試みてください。 アプリケーションを引き続き実行するとさらに多くのオブジェクトが除去される場合、このアプリケーションは EJB キャッシュ・スイープ間との間でキャッシュが保有できる量を超える Bean にアクセスしたり新規 Bean を作成したりしており、既存の Bean を再利用していいない ことを意味します。

      エンティティー Bean にオプション C キャッシングを使用すること、あるいは アプリケーションがもう必要のなくなったステートフル・セッション Bean を除去していないかどうかを確認することを検討します。

      注: オプション C キャッシングを使用して構成されたエンティティー 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 キャッシュ・トレースを使用不可にします。
   キャッシュを適切にチューニングすると、トレースを除去し、古いログを削除して、サーバーを再始動できます。