Speicher dimensionieren und Partitionsanzahl berechnen

Sie können die für Ihre spezielle Konfiguration benötigte Speicherkapazität und Partitionsanzahl berechnen.

Achtung: Verwenden Sie diesen Artikel, wenn Sie den Kopiermodus COPY_TO_BYTES nicht verwenden. Wenn Sie den Modus COPY_TO_BYTES verwenden, ist die Speicherkapazität sehr viel geringer und die Vorgehensweise bei der Berechnung anders. Weitere Informationen zu diesem Modus finden Sie unter Kopiermodus optimieren.
WebSphere eXtreme Scale speichert Daten im Adressraum von Java Virtual Machines (JVM). Jede JVM stellt Prozessorplatz für die Bearbeitung von Erstellungs-, Abruf-, Aktualisierungs- und Löschaufrufen für Daten bereit, die in der JVM gespeichert sind. Außerdem stellt jede JVM Speicherplatz für Dateneinträge und Replikate bereit. Java-Objekte variieren in ihrer Größe, und deshalb müssen Sie Messungen durchführen, um die benötigte Speicherkapazität zu schätzen.

Zur Dimensionierung des benötigten Speichers laden Sie Ihre Anwendungsdaten in eine einzige JVM. Wenn die Heapspeicherbelegung einen Wert von 60 % erreicht, notieren Sie die Anzahl der verwendeten Objekte. Diese Zahl ist die empfohlene maximale Objektanzahl für jede Ihrer JVMs. Für eine möglichst genaue Dimensionierung sollten Sie realistische Daten verwenden und alle definierten Indizes einbeziehen, weil Indizes auch Speicher belegen. Die beste Methode für die Speicherdimensionierung ist die Durchführung einer ausführlichen Garbage-Collection (mit verbosegc), da diese Ausgabe Ihnen die Zahlen nach der Garbage-Collection liefert. Sie können die Heapspeicherbelegung jederzeit über MBeans oder über das Programm abfragen, aber diese Abfragen liefern Ihnen nur eine aktuelle Momentaufnahme des Heapspeichers, die nicht erfassten Garbage (fehlerhafte Daten) enthalten kann. Deshalb ist die Verwendung dieser Methode keine genaue Indikation für den belegten Speicher.

Konfiguration vertikal skalieren

Anzahl der Shards pro Partition (numShardsPerPartition)
Zum Berechnen der Shard-Anzahl pro Partition bzw. des Werts von "numShardsPerPartition" addieren Sie 1 für das primäre Shard und die Gesamtanzahl der gewünschten Replikat-Shards. Weitere Informationen zur Partitionierung finden Sie unter Partitionierung.
numShardsPerPartition = 1 + Gesamtanzahl_der_Replikate

Anzahl der JVMs (minNumJVMs)

Für die vertikale Skalierung der Konfiguration müssen Sie zuerst die maximale Anzahl an Objekten festlegen, die insgesamt gespeichert werden müssen. Verwenden Sie die folgende Formel, um die Anzahl der benötigten JVMs zu bestimmen:
minNumJVMS=(numShardsPerPartition * numObjs) / numObjsPerJVM
Runden Sie diesen Wert auf die nächst höhere ganze Zahl auf.

Anzahl der Shards (numShards)

Bei der endgültigen Größe sollten Sie 10 Shards für jede JVM verwenden. Wie zuvor beschrieben, hat jede JVM ein primäres Shard und (N-1) Replikat-Shards bzw. in diesem Fall neun Replikate. Da Sie bereits eine Zahl für die Java Virtual Machines haben, in denen die Daten gespeichert werden, können Sie die JVM-Zahl mit 10 multiplizieren, um die Anzahl der Shards zu bestimmen:
numShards = minNumJVMs * 10 Shards/JVM

Anzahl der Partitionen

Wenn eine Partition ein einziges primäres Shard und ein einziges Replikat-Shard hat, hat die Partition zwei Shards (das primäre Shard und das Replikat-Shard). Die Anzahl der Partitionen entspricht der Shard-Anzahl, geteilt durch 2, aufgerundet auf die nächst höhere Primzahl. Wenn die Partition ein primäres Shard und zwei Replikat-Shards hat, entspricht die Anzahl der Partitionen der Shard-Anzahl, geteilt durch 3, aufgerundet auf die nächst höhere Primzahl.
numPartitions = numShards / numShardsPerPartition

Skalierungsbeispiel

In diesem Beispiel wird von einer anfänglichen Eintragsanzahl von 250 Millionen ausgegangen. Jedes Jahr nimmt die Anzahl der Einträge um etwa 14 % zu. Nach sieben Jahren sind insgesamt 500 Millionen Einträge vorhanden. Deshalb müssen Sie Ihre Kapazität entsprechend planen. Für die hohe Verfügbarkeit wird ein einziges Replikat benötigt. Mit einem Replikat verdoppelt sich die Anzahl der Einträge, d. h. auf 1.000.000.000 Einträge. Zu Testzwecken können 2 Millionen Einträge in jeder JVM gespeichert werden. Laut den Berechnungen wird dann in diesem Szenario die folgende Konfiguration benötigt:

Anfangskonfiguration

Basierend auf den vorherigen Berechnungen beginnen Sie mit 250 Java Virtual Machines und steigern sich dann im Lauf von fünf Jahren auf 500 Java Virtual Machines. Mit dieser Konfiguration können Sie ein inkrementelles Wachstum verwalten, bis Sie die endgültige Anzahl von Einträgen erreichen.

In dieser Konfiguration werden ungefähr 200.000 Einträge pro Partition (500 Millionen Einträge, geteilt durch 2503 Partitionen) gespeichert. Setzen Sie den Parameter numberOfBuckets in der Map, die die Einträge enthält, auf die nächst höhere Primzahl setzen (in diesem Beispiel 70887), die das Verhältnis bei ungefähr drei hält.

Erreichen der maximalen Anzahl an Java Virtual Machines

Wenn Sie die maximale Anzahl von 500 Java Virtual Machines erreichen, können Sie Ihr Datengrid trotzdem weiter vergrößern. Da die Anzahl der Java Virtual Machines über 500 steigt, fällt die Shard-Anzahl für jede JVM unter 10, was unter der empfohlenen Zahl liegt. Die Shards werden größer, was zu Problemen führen kann. Wiederholen Sie den Dimensionierungsprozess unter Berücksichtigung des künftigen Wachstums, und setzen Sie die Partitionsanzahl zurück. Dieses Verfahren erfordert einen vollständigen Neustart bzw. Außerbetriebnahme des Datengrids.

Anzahl der Server

Achtung: Verwenden Sie unter keinen Umständen Paging auf einem Server.
Die Speicherbelegung einer einzigen JVM ist höher als die Größe des Heapspeichers. Bei einem Heapspeicher mit einer Größe von 1 GB für eine JVM werden tatsächlich 1,4 GB Realspeicher belegt. Bestimmen Sie den verfügbaren freien Arbeitsspeicher des Servers. Teilen Sie die Arbeitsspeicherkapazität durch den Speicher pro JVM, um die maximale Anzahl an Java Virtual Machines auf dem Server zu erhalten.