データの断片化が起きているか確かめるには？
なお、フラグメントが発生しているかどうかを判別する方法は以下のとおりです。まずは、管理コンソールで、ORBトレース（com.ibm.CORBA.Debug、およびcom.ibm.CORBA.CommTrace）の設定を行います。
さらに、管理コンソールから、「ORBRas」トレースを設定します。
その後、サーバの再起動を行い、EJBに対してリクエストを送ります。traceファイル（デフォルト設定は、${SERVER_LOG_ROOT}/trace.log）に、設定されたフラグメント・サイズや実際にフラグメントが発生しているかどうかといった情報が記述されます。
【2】EJBコンテナのチューニング
2つ目は、EJBコンテナに対するチューニングです。EJBコンテナのチューニング項目は、以下の3つなどがあります。
- EJBキャッシュ・サイズ
- EJBコンテナのプール・サイズ
- EJBコンテナのプライマリー・キー・ミューテーション
（1）EJBキャッシュ・サイズ
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
キャッシュ・サイズの設定は、管理コンソールから行います。設定としてはハッシュ・テーブルのバケット数を指定し、その際には、素数を指定します。デフォルト値は2053です。
キャッシュ・サイズの調整を行うための情報収集は以下のように実施します。
まず、管理コンソールから診断トレース・サービスに以下の設定を追加します。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
その後、サーバの再起動を行い、EJBに対してリクエストを送ります。traceファイルに、以下のようなメッセージが記録されます。
なお、今回はキャッシュ・サイズ不足の環境を作るために、あえてキャッシュ・サイズを小さく設定しました（デフォルト値2053を101に変更）。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
上記例で、「Cache limit」というキーワードを見てみましょう。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
という行があります。最初の値「0」は、EJBキャッシュに存在するEJBの数です。次の値「101」は、EJBキャッシュ・サイズに設定した値です。
次に、「Cache limit not reached」と「Cache limit exceeded」に注目します。「Cache limit not reached」は、キャッシュ・サイズに余裕があることを示しており、場合によっては、キャッシュ・サイズを必要以上に大きく設定していることにもなります。その場合には、キャッシュ・サイズを小さくすることにより、メモリを有効に活用できます。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
「Cache limit exceeded」ですが、これは、キャッシュ・サイズ設定で指定した値以上にEJBが現在使用されていることを示しており、キャッシュ・サイズの設定が不適切であることを意味します。
実施には、EJBキャッシュ・サイズで設定した値以上のEJBをキャッシュできます。いい換えれば、EJBコンテナは設定値を超えた場合でも、キャッシュすることをやめません。
キャッシュ・サイズの設定値を超えた場合には、EJBコンテナはキャッシュ・サイズ指定値よりも少なくなるようにキャッシュのクリアを行います。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
Statefull Session Beanあるいは、Commit Option AかBのEntity Beanを使用している場合に、「Evicted =」という文字列がtraceファイルに記録されていたなら、キャッシュの有効活用ができていない可能性が高いです。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
その場合には、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を伴い、パフォーマンス性能に影響を与えます。
Copyright © ITmedia, Inc. All Rights Reserved.