IBM eXtremeMemory und IBM eXtremeIO konfigurieren

Wenn Sie eXtremeMemory konfigurieren, können Sie Objekte im nativen Speicher anstelle des Java-Heapspeichers speichern. Die Konfiguration von eXtremeMemory aktiviert eXtremeIO, einen neuen Transportmechanismus. Durch die Auslagerung von Objekten aus dem Java-Heapspeicher können Sie Garbage-Collection-Pausen vermeiden und damit eine konstantere Leistung und vorhersehbare Antwortzeiten erzielen.

Vorbereitende Schritte

Informationen zu diesem Vorgang

Die JVM stützt sich bei der Erfassung, Verkleinerung und Vergrößerung des Prozessspeichers auf Nutzungsheuristik. Der Garbage-Collector führt diese Operationen aus. Durch die Garbage-Collection entstehen jedoch Kosten. Die Kosten für die Garbage-Collection nehmen mit der Größe des Heapspeichers und der Anzahl der Objekte im Datengrid zu. Die JVM stellt verschiedene heuristische Verfahren für verschiedene Anwendungsfälle und Ziele bereit: optimaler Durchsatz, optimale Pausenzeiten, auf dem Objektalter basierende Garbage-Collection, gleichmäßige Verteilung und Garbage-Collection in Echtzeit. Kein heuristisches Verfahren ist perfekt. Ein einziges heuristisches Verfahren kann nicht für alle Konfigurationen geeignet sein.

WebSphere eXtreme Scale verwendet Datencaching mit verteilten Maps, die Einträge mit einem bekannten Lebenszyklus haben. Dieser Lebenszyklus enthält die folgenden Operationen: GET, INSERT, DELETE und UPDATE. Durch die Verwendung dieser bekannten Map-Lebenszyklen können eXtremeMemory und eXtremeIO den Speicher effizienter nutzen als die JVM-Nutzungsheuristik.

Die folgende Abbildung veranschaulicht, wie mit eXtremeMemory konsistentere relative Antwortzeiten in der Umgebung erzielt werden. Im Bereich der hohen Perzentile sind die relativen Antwortzeiten bei Anforderungen, die eXtremeMemory verwenden, wesentlich kürzer. In der Abbbildung sind die 95-100 Perzentile dargestellt.

.
Abbildung 1. Antwortzeiten von eXtremeMemory und Heapspeicher im Vergleich
Die relativen Antwortzeiten werden mit steigendem Antwortzeitperzentil länger. Die relativen Antwortzeiten sind bei eXtremeMemory sehr viel kürzer als beim Heapspeicher.
Wenn Sie eXtremeMemory verwenden, wird eXtremeIO für die Kommunikation zwischen Container-Servern verwendet. Objekte werden im Container-Server in Bytes serialisiert. Zum Aktivieren von eXtremeIO und eXtremeMemory setzen Sie die erforderlichen Servereigenschaften in allen Container-Servern im Datengrid und starten dann die Server erneut.

Vorgehensweise

  1. Optional: Richtigen Wert für die Eigenschaft maxXMSize ermitteln.
    1. Bestimmen Sie die Größe pro Eintrag in Ihrer vorhandenen Konfiguration. Führen Sie den Befehl xscmd -c showMapSizes aus, um diese Größe zu bestimmen.
    2. Berechnen Sie den Wert für maxXMSize. Um die maximale Gesamtgröße der Einträge (maximale_Gesamtgröße) zu erhalten, multiplizieren Sie die Größe_pro_Eintrag mit maximale_Eintragsanzahl. Verwenden Sie nicht mehr als 60 % von maxXMSize, um die Verarbeitung der Metadaten zu berücksichtigen. Multiplizieren Sie maximale_Gesamtgröße mit 1,65, um den Wert von maxXMSize zu erhalten.
  2. Aktualisieren Sie die Servereigenschaftendatei für jeden Container-Server in der Konfiguration, um den neuen Transport zu aktivieren. Die folgenden Servereigenschaften aktivieren den neuen Transport:
    Erforderliche Eigenschaften
    enableXM
    Wenn Sie diese Eigenschaft auf true setzen, wird IBM® eXtremeMemory auf dem Server aktiviert und der Server für die Verwendung von IBM eXtremeIO für synchrone und asynchrone Replikation konfiguriert. Cacheeinträge werden im nativen Speicher und nicht im Java-Heapspeicher gespeichert. Alle Container-Server im Datengrid müssen denselben Wert für die Eigenschaft enableXM verwenden.

    Standardwert: false

    Empfohlene Eigenschaften
    maxXMSize
    Letzt die maximale Speicherkapazität in Megabyte fest, die dem Server für den eXtremeMemory-Speicher zur Verfügung steht.

    Standardeinstellung: 25 % des Gesamtspeichers auf dem System

    Optionale Eigenschaften
    maxXIONetworkThreads
    Legt die maximale Anzahl an Threads fest, die dem Thread-Pool des eXtremeIO-Transportnetzes zugeordnet werden.

    Standardeinstellung: 50

    minXIONetworkThreads
    Legt die Mindestanzahl an Threads fest, die dem Thread-Pool des eXtremeIO-Transportnetzes zugeordnet werden.

    Standardeinstellung: 50

    maxXIOWorkerThreads
    Legt die maximale Anzahl an Threads fest, die dem Thread-Pool für die Verarbeitung von eXtremeIO-Transportanforderungen zugeordnet werden.

    Standardeinstellung: 128

    minXIOWorkerThreads
    Legt die Mindestanzahl an Threads fest, die dem Thread-Pool für die Verarbeitung von eXtremeIO-Transportanforderungen zugeordnet werden.

    Standardeinstellung: 128

    xioChannel.xioContainerTCPNonSecure.Port
    Gibt die Nummer des nicht sicheren Listener-Ports von eXtremeIO auf dem Server an. Wenn Sie keinen Wert festlegen, wird ein ephemerer Port verwendet. Diese Eigenschaft wird nur verwendet, wenn die Eigenschaft transportType auf TCP/IP gesetzt ist.

    xioChannel.xioContainerTCPSecure.Port
    Gibt die SSL-Portnummer von eXtremeIO auf dem Server an. Diese Eigenschaft wird nur verwendet, wenn die Eigenschaft transportType auf SSL-Supported oder SSL-Required gesetzt ist.
  3. Starten Sie die Container-Server erneut, damit der neue Transportmechanismus verwendet wird. Weitere Informationen finden Sie unter Eigenständige Server starten und stoppen und Server in einer Umgebung von WebSphere Application Server starten und stoppen.