Evictor は、データ・グリッドからデータを削除します。時間ベースの Evictor を設定できます。あるいは、Evictor は BackingMap に関連付けられているため、BackingMap インターフェースを使用してプラグ可能 Evictor を指定することもできます。
エントリーの期限切れがないように、それによってマップからエントリーが除去されることがないように指定します。
作成された時に応じてエントリーが除去されるように指定します。
CREATION_TIME ttlType を使用している場合、Evictor は、作成からの時間がその TimeToLive 属性値と等しいときにエントリーを除去します。TimeToLive 属性 TTL 値は、アプリケーション構成でミリ秒単位で設定されます。 TTL TimeToLive 属性値を 10 秒に設定すると、エントリーは挿入の 10 秒後に自動的に除去されます。
この値を作成時間 Evictor タイプ CREATION_TIME ttlType に設定する場合は注意が必要です。この Evictor は、一定時間にのみ使用される、キャッシュへの妥当な追加量がある場合に、最も有効に使用されます。 このストラテジーによって、作成されたものはすべて、一定時間後に除去されます。
作成時間 Evictor タイプ CREATION_TIME ttlType は、20 分以下の間隔で株価情報を最新表示するようなシナリオで役立ちます。 例えば、ある Web アプリケーションは株価情報の取得をしますが、最新情報を取得することは重要でないとします。この場合、株価情報は 20 分間、グリッド ObjectGrid にキャッシュされます。 20 分後、グリッド ObjectGrid マップの有効期限が切れ、除去されます。ほぼ 20 分ごとに、グリッド ObjectGrid マップは Loader プラグインを使用してそのデータをデータベースのデータでリフレッシュします。 データベースは 20 分ごとに最新の株価情報によって更新されます。
(読み取りか更新かに関わらず) 最後にアクセスされた時に応じてエントリーが除去されるように指定します。
最後に更新された時に応じてエントリーが除去されるように指定します。
最終アクセス時間 LAST_ACCESS_TIME または最終更新時間の Evictor タイプ LAST_UPDATE_TIME ttlType 属性を使用している場合は、作成時間 Evictor CREATION_TIME ttlType を使用している場合よりも TTL 値 TimeToLive を低い数に設定します。エントリー TimeToLive 属性は、アクセスされるたびにリセットされるからです。言い換えれば、TimeToLive 属性が 15 で、エントリーが 14 秒間存在し、それからアクセスされた場合、このエントリーはあと 15 秒間有効期限が切れることはありません。TTL 値 TimeToLive を比較的高い数値に設定した場合は、多くのエントリーがまったく除去されなくなる可能性があります。 ただし、この値を 15 秒程度に設定すると、エントリーは頻繁にアクセスされない場合に除去されることになります。
LAST_ACCESS_TIME または最終更新時間 Evictor タイプ LAST_UPDATE_TIME ttlType は、グリッド ObjectGrid マップを使用してクライアントからのセッション・データを保持するようなシナリオで役立ちます。セッション・データは、クライアントがそのセッション・データを一定時間使用しない場合は破棄する必要があります。 例えば、セッション・データは、クライアントによるアクティビティーが 30 分間なかった後にタイムアウトになるとします。 この場合、最終アクセス時間 LAST_ACCESS_TIME または LAST_UPDATE_TIME 最終更新時間の Evictor タイプを使用し、TTL 値 TimeToLive 属性を 30 分に設定するのが、このアプリケーションにおいて適切です。
独自の Evictor を作成することもできます。詳しくは、カスタム Evictor の作成を参照してください。
デフォルトの TTL Evictor は、時刻ベースの除去ポリシーを使用し、 BackingMap 内のエントリーの数は、エントリーの有効期限の時間には影響を及ぼしません。オプションのプラグ可能 Evictor を使用して、時刻ではなく、存在するエントリー数に基づいてエントリーを除去することができます。
BackingMap は、トランザクション内でエントリーが作成、変更、または除去されると Evictor に通知します。 BackingMap は、これらのエントリーをトラッキングし、BackingMap インスタンスから 1 つ以上のエントリーをいつ除去するかを選択します。
BackingMap インスタンスには、最大サイズについての構成情報はありません。 代わりに、Evictor の振る舞いを制御する Evictor プロパティーが設定されます。 LRUEvictor と LFUEvictor の両方の最大サイズ・プロパティーを使用して、 最大サイズを超えた後、Evictor がエントリーを除去開始するようにします。 TTL Evictor と同様に、LRU Evictor と LFU Evictor では、 最大エントリー数に達した場合、パフォーマンスへの影響を最小化するためにエントリーを直ちに除去することはありません。
特定のアプリケーションに LRU または LFU 除去アルゴリズムが適していない場合、独自の Evictor を作成して、除去ストラテジーを作成できます。
組み込み Evictor はすべて、メモリー・ベースの除去をサポートし、これは、BackingMap の evictionTriggers 属性を「MEMORY_USAGE_THRESHOLD」に設定することにより使用可能にできます。 BackingMap での evictionTriggers 属性の設定方法について詳しくは、BackingMap インターフェースおよびObjectGrid 記述子 XML ファイルを参照してください。
メモリー・ベースの除去は、ヒープ使用量のしきい値に基づいています。BackingMap でメモリー・ベースの除去が使用可能になっていて、BackingMap に組み込み Evictor がある場合、使用量のしきい値は、まだ設定されていなければ、合計メモリーのデフォルトのパーセンテージに設定されます。
メモリー・ベースの除去を使用している場合、 ガーベッジ・コレクションしきい値を、ターゲット・ヒープ使用率と同じ値に構成する必要があります。 例えば、メモリー・ベースの除去のしきい値が 50 パーセントに設定されていて、ガーベッジ・コレクションのしきい値がデフォルトの 70 パーセント・レベルであると、ヒープ使用率は 70 パーセントまで上がる可能性があります。 このヒープ使用率の増加が起きるのは、メモリー・ベースの除去が 1 ガーベッジ・コレクション・サイクルの後にのみトリガーされるためです。
デフォルトの使用量しきい値のパーセンテージを変更するには、eXtreme Scale サーバー・プロセスのコンテナーおよびサーバーのプロパティー・ファイルで memoryThresholdPercentage プロパティーを設定します。 クライアント・プロセスでターゲットの使用量しきい値を設定する場合は、MemoryPoolMXBean を使用できます。
WebSphere eXtreme Scale が使用するメモリー・ベースの除去アルゴリズムは、使用中のガーベッジ・コレクションのアルゴリズムの動作に影響を受けやすいのです。 メモリー・ベースの除去の最善のアルゴリズムは、IBM® デフォルト・スループット・コレクターです。世代ガーベッジ・コレクション・アルゴリズムは、好ましくない動作を引き起こす可能性があるため、メモリー・ベースの除去と一緒に、このアルゴリズムを使用すべきではありません。
使用量しきい値のパーセンテージを変更するには、eXtreme Scale サーバー・プロセスのコンテナーおよびサーバーのプロパティー・ファイルで memoryThresholdPercentage プロパティーを設定します。
実行時に、メモリー使用量がターゲットの使用量しきい値を超えると、メモリー・ベースの Evictor はエントリーの除去を開始して、メモリー使用量がターゲットの使用量しきい値を下回るようにします。 ただし、継続してシステム・ランタイムによるメモリー消費が迅速に進むと、除去速度が十分速くても、メモリー不足エラーが起こる可能性がなくなるという保証はありません。