あなたのEJBシステム遅くないですか？：WebSphereサーバ・チューニング入門（5）（2/3 ページ）

» 2008年01月24日 00時00分公開

[上野憲一郎，日本アイ・ビー・エム]

前のページへ 1|2|3 次のページへ

データの断片化が起きているか確かめるには？

　なお、フラグメントが発生しているかどうかを判別する方法は以下のとおりです。まずは、管理コンソールで、ORBトレース（com.ibm.CORBA.Debug、およびcom.ibm.CORBA.CommTrace）の設定を行います。

図4　ORBトレース（com.ibm.CORBA.Debug、およびcom.ibm.CORBA.CommTrace）の設定

　さらに、管理コンソールから、「ORBRas」トレースを設定します。

図5　「ORBRas」トレースの設定

　その後、サーバの再起動を行い、EJBに対してリクエストを送ります。traceファイル（デフォルト設定は、${SERVER_LOG_ROOT}/trace.log）に、設定されたフラグメント・サイズや実際にフラグメントが発生しているかどうかといった情報が記述されます。

【2】EJBコンテナのチューニング

　2つ目は、EJBコンテナに対するチューニングです。EJBコンテナのチューニング項目は、以下の3つなどがあります。

EJBキャッシュ・サイズ
EJBコンテナのプール・サイズ
EJBコンテナのプライマリー・キー・ミューテーション

（1）EJBキャッシュ・サイズ

キャッシュ・サイズ

              ＝ 

          （1トランザクション当たりのCommit Option BおよびCのEntity Beanの最大数）

              ＊ 

          （最大同時トランザクション数）

              ＋

          Commit Option AのEntity Beanの最大数

              ＋

          最大アクティブStatefull Session Bean数

              ＋

          最大アクティブStateless Session Bean数

　キャッシュ・サイズの設定は、管理コンソールから行います。設定としてはハッシュ・テーブルのバケット数を指定し、その際には、素数を指定します。デフォルト値は2053です。

図6　EJBキャッシュ・サイズの設定

　キャッシュ・サイズの調整を行うための情報収集は以下のように実施します。

　まず、管理コンソールから診断トレース・サービスに以下の設定を追加します。

com.ibm.ejs.util.cache.BackgroundLruEvictionStrategy=all

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

図7　EJBキャッシュ用トレースの設定

　その後、サーバの再起動を行い、EJBに対してリクエストを送ります。traceファイルに、以下のようなメッセージが記録されます。

　なお、今回はキャッシュ・サイズ不足の環境を作るために、あえてキャッシュ・サイズを小さく設定しました（デフォルト値2053を101に変更）。

[12/1/07 22:19:13:254 JST] 00000015 BackgroundLru 3   EJB Cache: Sweep (3,40) - Cache limit not reached : 0/101

          [12/1/07 22:19:22:259 JST] 00000015 BackgroundLru >  EJB Cache: Sweep (6,40) - Cache limit exceeded : 801/101 Entry

          [12/1/07 22:19:22:261 JST] 00000015 CacheElementE 3   Empty : EJB Cache returned = 824, 815% capacity (lookup avg = 4.9696603, max = 16)

          [12/1/07 22:19:22:261 JST] 00000015 CacheElementE 3   Empty : EJB Cache size[buckets] = 0[0], 2[2], 3[1], 4[4], 5[7], 6[9], 7[20], 8[16], 9[10], 10[14], 11[9], 12[5], 13[3], 16[1]

          [12/1/07 22:19:22:261 JST] 00000015 CacheElementE 3   reset : EJB Cache = 850, index = 85/101

          [12/1/07 22:19:22:261 JST] 00000015 BackgroundLru <  EJB Cache: Sweep (6,40) - Evicted = 0 : 853/101 Exit

　上記例で、「Cache limit」というキーワードを見てみましょう。

[12/1/07 22:19:13:254 JST] 00000015 BackgroundLru 3 EJB Cache: Sweep (3,40) - Cache limit not reached : 0/101

　という行があります。最初の値「0」は、EJBキャッシュに存在するEJBの数です。次の値「101」は、EJBキャッシュ・サイズに設定した値です。

　次に、「Cache limit not reached」と「Cache limit exceeded」に注目します。「Cache limit not reached」は、キャッシュ・サイズに余裕があることを示しており、場合によっては、キャッシュ・サイズを必要以上に大きく設定していることにもなります。その場合には、キャッシュ・サイズを小さくすることにより、メモリを有効に活用できます。

[12/1/07 22:19:13:254 JST] 00000015 BackgroundLru 3 EJB Cache: Sweep (3,40) - Cache limit not reached : 0/101

　「Cache limit exceeded」ですが、これは、キャッシュ・サイズ設定で指定した値以上にEJBが現在使用されていることを示しており、キャッシュ・サイズの設定が不適切であることを意味します。

　実施には、EJBキャッシュ・サイズで設定した値以上のEJBをキャッシュできます。いい換えれば、EJBコンテナは設定値を超えた場合でも、キャッシュすることをやめません。

　キャッシュ・サイズの設定値を超えた場合には、EJBコンテナはキャッシュ・サイズ指定値よりも少なくなるようにキャッシュのクリアを行います。

[12/1/07 22:19:22:259 JST] 00000015 BackgroundLru > EJB Cache: Sweep (6,40) - Cache limit exceeded : 801/101 Entry

　Statefull Session Beanあるいは、Commit Option AかBのEntity Beanを使用している場合に、「Evicted =」という文字列がtraceファイルに記録されていたなら、キャッシュの有効活用ができていない可能性が高いです。

[12/1/07 22:19:22:261 JST] 00000015 BackgroundLru < EJB Cache: Sweep (6,40) - Evicted = 0 : 853/101 Exit

　その場合には、EJBキャッシュ・サイズを大きくし、再度、traceファイルを確認します。キャッシュ・サイズを増やしても効果が見られない場合（Evictedが記録され続ける場合）は、キャッシュによる既存のEJB再利用が利用できないということになります。

　Commit Option Cの利用を検討するか、不要になったStatefull Session Beanが削除されずに残っているかどうかを確認する（アプリケーション・コードを見直す）ことが必要になるでしょう。

　Commit Option Cを設定したEntity Beanは、トランザクション内でのみキャッシュされ、トランザクション中はずっとキャッシュに保持されます。従って、「cache sweep」が起きても「evict」されることはありません。そして、トランザクションが完了した際に、キャッシュから削除されます。

　Stateless Session BeanあるいはCommit Option Cを設定したEntity Beanのみを利用している場合には、EJBキャッシュの「クリーンアップ間隔」（図6）を長く設定することを検討する必要もあります。というのも、Stateless Session Beanは、EJBキャッシュにはキャッシュされませんし、Commit Option Cを設定したEntity BeanはLRUストラテジーによる「evict」はされません。従って、「sweep」を頻繁に実施する必要はないのです。

　Stateless Session Bean、あるいはCommit Option Cを設定したEntity Beanのみを利用している場合には、「Evicted = 0」という記録がトレースファイルに見つかります（上記例が該当します）。

　なお、キャッシュが満杯になると、EJBコンテナがLRUに基づきStatefull Session Beanのパッシベーション処理を行います。パッシベーション処理は、指定したディレクトリ（非活性化ディレクトリ、図8参照）にオブジェクトを書き出すため、ディスクI/Oを伴い、パフォーマンス性能に影響を与えます。