Bereinigungsprogramme (Evictor) entfernen Daten aus dem Datengrid. Sie können ein zeitbasiertes Bereinigungsprogramm definieren. Da Bereinigungsprogramme BackingMaps zugeordnet werden, verwenden Sie die Schnittstelle "BackingMap", um das Plug-in-Bereinigungsprogramm anzugeben.
Gibt an, dass Einträge nicht verfallen und deshalb nicht aus der Map entfernt werden.
Gibt an, dass Einträge auf der Basis der Erstellungszeit entfernt werden.
Wenn Sie das Bereinigungsprogramm "Erstellungszeit" (CREATION_TIME ttlType) verwenden möchten, löscht das Bereinigungsprogramm einen Eintrag, wenn dessen Lebensdauer ab Erstellung seinem TTL-Wert (Attribut TimeToLive) entspricht, das in Ihrer Anwendungskonfiguration in Millisekunden definiert ist. Wenn Sie den TTL-Wert (Attribut TimeToLive) auf 10 Sekunden setzen, wird der Eintrag automatisch zehn Sekunden nach seinem Einfügen gelöscht.
Gehen Sie beim Definieren dieses Werts für den Bereinigungsprogrammtyp "Erstellungszeit" (ttlType CREATION_TIME) mit Vorsicht vor. Die Verwendung dieses Bereinigungsprogramms empfiehlt sich, wenn dem Cache sehr viele Einträge hinzugefügt werden, die nur für eine bestimmte Zeit verwendet werden. Mit dieser Strategie werden alle erstellten Einträge nach der festgelegten Zeit entfernt.
Der Bereinigungsprogrammtyp "Erstellungszeit" (ttlType CREATION_TIME) ist in Szenarien wie der Aktualisierung von Börsennotierungen in einem 20-Minuten-Intervall hilfreich. Angenommen, eine Webanwendung ruft Börsennotierungen ab. Die Topaktualität der Notierungen ist jedoch nicht kritisch. In diesem Fall werden die Börsennotierungen 20 Minuten lang in einem Grid (ObjectGrid) zwischengespeichert. Nach 20 Minuten verfallen die Grid-Map-Einträge (ObjectGrid) und werden daraufhin entfernt. Ungefähr alle zwanzig Minuten verwendet das Datengrid das Loader-Plug-in, um die Daten mit Daten aus der Datenbank zu aktualisieren. Die Datenbank wird alle 20 Minuten mit den topaktuellen Börsennotierungen aktualisiert.
Gibt an, dass Einträge auf der Basis der letzten Zugriffszeit (Lese- oder Aktualisierungszugriff) entfernt werden.
Gibt an, dass Einträge auf der Basis der Uhrzeit der letzten Aktualisierung entfernt werden.
Wenn Sie den Bereinigungsprogrammtyp "Letzte Zugriffszeit" (LAST_ACCESS_TIME) oder "Letzte Aktualisierungszeit" (Attribut ttlType LAST_UPDATE_TIME) verwenden, setzen Sie den TTL-Wert (Attribut TimeToLive) auf eine niedrigere Zahl als beim Bereinigungsprogrammtyp "Erstellungszeit" (ttlType CREATION_TIME). Die Einträge (Attribut TimeToLive) bei jedem Zugriff zurückgesetzt. Anders ausgedrückt, wenn der Wert des Attributs TimeToLive kleiner als 15 ist und ein Eintrag eine Lebensdauer von 14 Sekunden hat, wenn der Zugriff erfolgt, bleibt der Eintrag für weitere 15 Sekunden gültig. Wenn Sie den TTL-Wert auf einen relativ hohen Wert setzen, werden viele Einträge nie gelöscht. Setzen Sie "TimeToLive" jedoch auf einen Wert von ungefähr 15 Sekunden, können Einträge entfernt werden, wenn nicht sehr häufig auf sie zugegriffen wird.
Die Bereinigungsprogrammtypen "Letzte Zugriffszeit" (LAST_ACCESS_TIME) und "Letzte Aktualisierungszeit" (LAST_UPDATE_TIME ttlType) sind in Szenarien wie dem Speichern von Sitzungsdaten eines Clients mithilfe einer Daten-Grid-Map hilfreich. Sitzungsdaten müssen gelöscht werden, wenn der Client die Sitzungsdaten innerhalb eines bestimmten Zeitraums nicht verwendet. Die Sitzungsdaten verfallen beispielsweise, wenn innerhalb von 30 Minuten keine Aktivität des Clients erfolgt. In diesem Fall eignet sich die Verwendung des Bereinigungsprogrammtyps "Letzte Zugriffszeit" (LAST_ACCESS_TIME) oder "Letzte Aktualisierungszeit" (LAST_UPDATE_TIME) mit einem TTL-Wert von 30 Minuten für diese Anwendung.
Sie können aber auch eigene Bereinigungsprogramme schreiben. Weitere Informationen hierzu finden Sie unter Angepassten Evictor schreiben.
Das TTL-Standardbereinigungsprogramm verwendet eine Bereinigungsrichtlinie, die auf Zeit basiert, und die Anzahl der Einträge in der BackingMap hat keine Auswirkung auf die Verfallszeit eines Eintrags. Sie können ein optionales Plug-in-Bereinigungsprogramm verwenden, um Einträge auf der Basis der Anzahl vorhandener Einträge und nicht auf der Basis der Zeit zu entfernen.
Die BackingMap informiert ein Bereinigungsprogramm, wenn Einträge in einer Transaktion erstellt, geändert oder entfernt werden. Die BackingMap verfolgt diese Einträge und entscheidet, wann Einträge aus der BackingMap-Instanz entfernt werden müssen.
Eine BackingMap-Instanz hat keine Konfigurationsdaten für eine maximale Größe. Stattdessen werden Eigenschaften des Bereinigungsprogramms definiert, um das Verhalten des Bereinigungsprogramms zu steuern. Die Bereinigungsprogramme "LRUEvictor" und "LFUEvictor" haben beide eine Eigenschaft für die maximale Größe, die das Bereinigungsprogramm anweist, mit dem Entfernen von Einträgen zu beginnen, wenn die maximale Größe überschritten wird. Wie das TTL-Bereinigungsprogramm entfernen auch die Bereinigungsprogramme "LRUEvictor" und "LFUEvictor" einen Eintrag möglicherweise nicht sofort, wenn die maximale Anzahl an Einträgen erreicht ist, um die Auswirkungen auf die Leistung zu minimieren.
Wenn der LRU- bzw. LFU-Bereinigungsalgorithmus für eine bestimmte Anwendung nicht angemessen ist, können Sie eigene Bereinigungsprogramme schreiben, um eine eigene Bereinigungsstrategie zu erstellen.
Alle integrierten Bereinigungsprogramme unterstützten die speicherbasierte Bereinigung, die in der Schnittstelle "BackingMap" aktiviert werden kann, indem das Attribut "evictionTriggers" der BackingMap auf MEMORY_USAGE_THRESHOLD gesetzt wird. Weitere Informationen zum Definieren des Attributs "evictionTriggers" in der BackingMap finden Sie unter Schnittstelle "BackingMap" und unter ObjectGrid-XML-Deskriptordatei.
Die speicherbasierte Bereinigung basiert auf einem Schwellenwert für die Auslastung des Heapspeichers. Wenn die speicherbasierte Bereinigung in der BackingMap aktiviert ist und die BackingMap ein integriertes Bereinigungsprogramm hat, wird der Schwellenwert für die Auslastung auf einen Standardprozentsatz des Gesamtspeichers gesetzt, wenn noch kein Schwellenwert definiert wurde.
Wenn Sie die speicherbasierte Bereinigung verwenden, müssen Sie den Schwellenwert für die Garbage-Collection auf denselben Wert wie die Zielauslastung des Heapspeichers setzen. Beispiel: Wenn der Schwellenwert für die speicherbasierte Bereinigung auf 50 Prozent und der Schwellenwert für die Garbage-Collection auf den Standardwert von 70 Prozent gesetzt wird, kann die Auslastung des Heapspeichers auf maximal 70 Prozent ansteigen. Diese Erhöhung der Heapspeicherauslastung findet statt, weil die speicherbasierte Bereinigung erst nach einem Garbage-Collection-Zyklus ausgelöst wird.
Wenn Sie den Standardprozentsatz für den Auslastungsschwellenwert ändern möchten, setzen Sie die Eigenschaft "memoryThresholdPercentage" in den Container- und Servereigenschaftendateien für eXtreme-Scale-Serverprozesse. Zum Definieren des Schwellenwerts für die Zielauslastung in einem Clientprozess können Sie die MBean "MemoryPoolMXBean" verwenden.
Der von WebSphere eXtreme Scale verwendete Algorithmus für die speicherbasierte Bereinigung reagiert auf das Verhalten des verwendeten Algorithmus für die Garbage-Collection. Der beste Algorithmus für die speicherbasierte Bereinigung ist der IBM® Standarddurchsatzcollector. Algorithmen für eine Garbage-Collection nach Objektalter können ein unerwünschtes Verhalten bewirken, und deshalb sollten Sie diese Algorithmen nicht für die speicherbasierte Bereinigung verwenden.
Wenn Sie den Prozentsatz für den Auslastungsschwellenwert ändern möchten, setzen Sie die Eigenschaft "memoryThresholdPercentage" in den Container- und Servereigenschaftendateien für eXtreme-Scale-Serverprozesse.
Wenn die Speicherbelegung zur Laufzeit den Schwellenwert für die Zielauslastung überschreitet, beginnen speicherbasierte Bereinigungsprogramme mit dem Entfernen von Einträgen und versuchen, die Speicherbelegung unterhalb des Schwellenwerts für die Zielauslastung zu halten. Es gibt jedoch keine Garantien, dass die Bereinigung schnell genug ist, um potenzielle abnormale Speicherbedingungen zu verhindern, wenn die Laufzeitumgebung des Systems weiterhin so schnell Speicher belegt.