Enterprise JavaBeans (EJB) キャッシュのサイズは、アプリケーション・サーバーのパフォーマンスに影響を及ぼすことがあります。EJB コンテナーを最適パフォーマンス・レベルにチューニングする手順の 1 つに、EJB キャッシュの微調整があります。
始める前に
注: このトピックでは、
1 つ以上のアプリケーション・サーバー・ログ・ファイルを参照します。推奨される代替案として、分散システムや IBM® i システムの SystemOut.log、SystemErr.log、trace.log、activity.log ファイルではなく、High Performance Extensible Logging (HPEL) ログおよびトレース・インフラストラクチャーを使用するようにサーバーを構成できます。また HPEL は、ネイティブ z/OS® ロギング機能と連携させて使用することができます。HPEL を使用する場合、LogViewer コマンド・ライン・ツールを
サーバー・プロファイルの bin ディレクトリーから使用して、すべてのログ・ファイルにアクセスし、
情報をトレースできます。HPEL の使用について詳しくは、HPEL を使用してのアプリケーションの
トラブルシューティングに関する情報を参照してください。
このタスクについて
以下の手順は、診断トレース・サービスを使用してキャッシュの最適なサイズを決める方法を説明します。
手順
- EJB キャッシュ・トレースを使用可能にします。 トレース・サービスの操作について詳しくは、『トレースによる処理』のトピックを参照してください。
![[IBM i]](../images/iseries.gif)
トレース・サービス設定の詳細については、『診断トレース・サービス設定』のトピックを参照してください。次のトレース・ストリングを使用するようにトレースをセットアップします。
com.ibm.ejs.util.cache.BackgroundLruEvictionStrategy=all=enabled:com.ibm.ejs.util.cache.CacheElementEnumerator=
all=enabled
![[IBM i]](../images/iseries.gif)
「最大ファイル・サイズ」を 200 MB 以上に設定します。
デフォルト値の 20MB のままにしておくと、20 MB のトレース・ログがいっぱいになり、トレースが折り返されてデータが失われることがあります。
![[IBM i]](../images/iseries.gif)
「ヒストリー・ファイルの最大数」を 5 に設定します。ファイル数は 5 つで十分であると考えられますが、これら 5 つのファイルがすべていっぱいになり、トレースの折り返しが発生する場合は、この値を増やしてください。
![[IBM i]](../images/iseries.gif)
サーバーを停止し、既存のログを削除してから、サーバーを始動します。
サーバーを停止して再始動します。
- 標準的な手順を実行してキャッシュ・トレース・データを収集します。 トレースを有効にした標準的な手順を実行することで、次のステップで分析する EJB キャッシュ・トレース・データを取得します。
- トレース出力を表示して分析します。
- トレース・ログを開きます。 表示する以下のトレース・ストリングのいずれか、または両方を探します。
![[IBM i]](../images/iseries.gif)
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
Trace: 2007/03/22 11:47:07.048 01 t=7A9690 c=UNK key=P8 (13007002)
ThreadId: 0000006a
FunctionName: com.ibm.ejs.util.cache.BackgroundLruEvictionStrategy
SourceId: com.ibm.ejs.util.cache.BackgroundLruEvictionStrategy
Category: FINEST
ExtendedMessage: EJB Cache: Sweep (23,40) - Cache limit not reached : 0/2053
Trace: 2007/03/22 11:54:16.755 01 t=7BD3B0 c=UNK key=P8 (13007002)
ThreadId: 0000006d
FunctionName: EJB Cache: Sweep (75,37) - Cache limit exceeded : 3801/2053
SourceId: com.ibm.ejs.util.cache.BackgroundLruEvictionStrategy
Category: FINER
ExtendedMessage: 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 キャッシュ・サイズ未満に保持することを試みます。
キャッシュ制限を超えた場合、トレース・ポイントが次のようになる場合があります。
![[IBM i]](../images/iseries.gif)
BackgroundLru < EJB Cache: Sweep (64,38) - Evicted = 50 : 3589/2053 Exit
EJB Cache: Sweep (64,38) - Evicted = 50 : 3589/2053
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" だけが表示されるはずです。
- トレース・ログを分析します。 Cache limit exceeded というトレース・ストリングを探します。
- このストリングは複数見つかる場合があります。
その場合はそれらすべてを調べて、EJB キャッシュ内の Bean の最大容量の値を見つけます。
EJB キャッシュ・サイズを、この容量値のほぼ 110% に再設定します。EJB キャッシュ・サイズの設定法については、後のステップで説明します。
- このトレース・ストリングが 1 つもない場合もあります。
これは、EJB キャッシュの容量 (最終目標) を越えていないことを意味しますが、初期分析中に最終目標が見えていないということは、キャッシュが大きすぎて不要なメモリーを使用している可能性もあります。
この場合は、キャッシュ制限を超えない限界までキャッシュ・サイズを
減らしてから、最適な値まで増やすことで、キャッシュをまだ調整する
必要があります。EJB キャッシュ・サイズの設定法については、後のステップで説明します。
ここでの最終目標は、リソースを浪費しないが、超過することもない値にキャッシュ制限を設定することです。
セットアップが適切な場合、トレース中に表示されるメッセージは「
Cache limit not reached」のみであり、容量の値は EJB キャッシュ設定値の 100% に近づきつつそれを超えない比率になります。
注: キャッシュ・サイズはデフォルト値の 2053 未満には設定変更しないことをお勧めします。
- 分析に基づいてキャッシュ設定値を変更してください。 この方法について詳しくは、『EJB キャッシュ設定』を参照してください。
![[IBM i]](../images/iseries.gif)
サーバーを停止し、すべてのログを削除し、サーバーを再始動します。
サーバーを停止して再始動します。
- 設定値に納得するまで、上記のステップを繰り返してください。
- EJB キャッシュ・トレースを使用不可にします。 キャッシュを適切にチューニングすると、トレースを除去し、古いログを削除して、サーバーを再始動できます。
次のタスク
分析の結果、EJB コンテナーの観点から EJB キャッシュを最適に設定することは可能ですが、その値は WebSphere® Application Server の観点からすると最適ではない可能性があります。
キャッシュ・サイズが大きい方がヒット数は高くなり、EJB キャッシュのパフォーマンスは向上しますが、メモリー使用量は増加します。
キャッシュに使用されるメモリーはその製品の他の領域では使用できないので、全体的なパフォーマンスが低下する可能性があります。
メモリーが豊富にあるシステムでは、パフォーマンスの低下は問題にならず、EJB キャッシュを適切にチューニングすることで全体的なパフォーマンスが向上します。
ただし、キャッシュを構成するときには、システムのパフォーマンスと EJB キャッシュのパフォーマンスを対比させて考慮する必要があります。