Java Virtual Machines optimieren

Sie müssen bestimmte Aspekte der JVM-Optimierung (Java Virtual Machine) berücksichtigen, um die beste Leistung mit WebSphere eXtreme Scale zu erzielen. In den meisten Fällen sind nur wenige bzw. gar keine speziellen JVM-Einstellungen erforderlich. Wenn viele Objekte im Datengrid gespeichert werden, passen Sie die Größe des Heapspeichers entsprechend an, um Speicherengpässe zu vermeiden.

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. Weitere Informationen finden Sie im Abschnitt IBM eXtremeMemory und IBM eXtremeIO konfigurieren.

Getestete Plattformen

Leistungstests wurden hauptsächlich auf AIX- (32 Wege), Linux- (vier Wege) und Windows-Computern (acht Wege) durchgeführt. Mit High-End-AIX-Computern können Sie Szenarien mit sehr vielen Threads testen, um Konfliktpunkte zu identifizieren und zu beheben.

Garbage-Collection

WebSphere eXtreme Scale erstellt temporäre Objekte für jede Transaktion, wie z. B. Anforderungs- und Antwortobjekte und eine Protokollfolge. Da sich diese Objekte auf die Effizienz der Garbage-Collection auswirken, ist die Optimierung der Garbage-Collection kritisch.

Alle modernen JVMs verwenden Algorithmen für parallele Garbage-Collection, d. h., durch den Einsatz weiterer Kerne können die Pausen zwischen den Garbage-Collections reduziert werden. Ein physischer Server mit acht Kernen hat eine schnellere Garbage-Collection als ein physischer Server mit vier Kernen.

Wenn die Anwendung ein großes Datenvolumen für jede Partition verwalten muss, kann die Garbage-Collection ein entscheidender Faktor sein. In einem Szenario, in dem hauptsächlich Leseoperationen durchgeführt werden, ist die Leistung selbst bei sehr großen Heapspeichern (20 GB und mehr) in Ordnung, wenn eine Garbage-Collection nach Objektalter verwendet wird. Wenn der Heapspeicher für die permanenten Objekte gefüllt ist, ist jedoch eine Pause zu bemerken, die proportional zur Größe des Live-Heapspeichers und der Anzahl der Prozessoren im Computer ist. Diese Pause kann auf kleineren Computern mit großen Heapspeichern sehr lang sein.

Garbage-Collection von IBM Virtual Machine for Java

Für IBM® Virtual Machine for Java verwenden Sie den Collector optavgpause in Szenarien mit einer hohene Aktualisierungsrate (100 % der Transaktionen ändern Einträge). Der Collector gencon funktioniert in Szenarien, in denen die Daten nur relativ selten aktualisiert werden (10 % der Zeit oder weniger), viel besser als der Collector optavgpause. Experimentieren Sie mit beiden Collector, um festzustellen, welcher sich besser in Ihrem Szenario eignet. Führen Sie die Collector mit aktivierter ausfühlicher Garbage-Collection aus, um zu prüfen, wie viel Zeit für die Garbage-Collection aufgebracht wird. Es wurden Szenarien gefunden, in denen 80 % der Zeit für die Garbage-Collection aufgebracht wurde, bis das Problem durch Optimierung behoben wurde.

Verwenden Sie den Parameter -Xgcpolicy, um den Garbage-Collection-Mechanismus zu ändern. Der Wert des Parameters -Xgcpolicy kann je nach verwendetem Garbage-Collector auf -Xgcpolicy:gencon oder -Xgcpolicy:optavgpause gesetzt werden.

Weitere Garbage-Collection-Optionen

Achtung: Wenn Sie eine JVM von Oracle verwenden, müssen Sie möglicherweise Anpassungen an deren JVM, adjustments to the default Standard-Garbage-Collection und der Optimierungsrichtlinie vornehmen.

WebSphere eXtreme Scale unterstützt WebSphere Real Time Java. Bei WebSphere Real Time Java sind die Antwortzeiten der Transaktionsverarbeitung für WebSphere eXtreme Scale konsitenter und vorhersehbar. Deshalb sind die Auswirkungen der Garbage-Collection und der Threadplanung weitgehend minimal. Die Auswirkungen werden so weit reduziert, dass die Standardabweichung bei den Antwortzeiten weniger als 10 % als beim regulären Java beträgt.

JVM-Leistung

WebSphere eXtreme Scale kann in verschiedenen Versionen von Java Platform, Standard Edition ausgeführt werden. WebSphere eXtreme Scale unterstützt Java SE Version 5, Java SE Version 6 und Java SE Version 7. Zur Steigerung der Entwicklerproduktivität und der Leistung verwenden Sie Java SE Version 5, Version 6 oder Java SE Version 7, um Annotationen und die verbesserte Garbage-Collection zu nutzen. WebSphere eXtreme Scale kann in 32-Bit- und 64-Bit-JVMs ausgeführt werden.

WebSphere eXtreme Scale wurde mit einem Teil der verfügbaren virtuellen Maschinen getestet, aber die Liste der unterstützten JVMs ist nicht exklusiv. Sie können WebSphere eXtreme Scale in jeder JVM der Edition 5 oder höher jedes Anbieters ausführen. Wenn jedoch ein Problem mit einer JVM eines Anbieters auftritt, müssen Sie sich an den JVM-Anbieter wenden, um Unterstützung zu erhalten. Verwenden Sie, wenn möglich, auf jeder Plattfom, die von WebSphere Application Server unterstützt wird, die JVM aus der Laufzeitumgebung von WebSphere.

Im Allgemeinen erzielen Sie mit der aktuellsten verfügbaren Version von Java Platform, Standard Edition die beste Leistung.

Größe des Heapspeichers

Es wird empfohlen, Heapspeicher mit einer Größe von 1 bis 2 GB für eine JVM mit vier Kernen zu verwenden. Die optimale Größe des Heapspeichers ist von den folgenden Faktoren abhängig:
  • Anzahl der Liveobjekte im Heapspeicher
  • Komplexität der Liveobjekte im Heapspeicher
  • Anzahl verfügbarer Kerne für die JVM

Eine Anwendung, die beispielsweise 10-K-Byte-Arrays speichert, kann einen viel größeren Heapspeicher haben als eine Anwendung, die komplexe POJO-Graphen verwendet.

Threadanzahl

Die Threadanzahl ist von verschiedenen Faktoren abhängig. Die Anzahl der Threads, die von einem einzelnen Shard verwaltet werden können, ist begrenzt. Ein Shard ist eine Instanz einer Partition. Ein Shard kann ein primäres Shard oder ein Replikat-Shard sein. Je mehr Shards jede JVM enthält, desto mehr Threads und mehr gemeinsame Datenzugriffspfade sind möglich. Jedes Shard ist so nebenläufig wie möglich, aber nichtsdestotrotz gibt es einen Grenzwert.

ORB-Anforderungen (Object Request Broker)

IBM SDK enthält eine IBM ORB-Implementierung, die mit WebSphere Application Server und WebSphere eXtreme Scale getestet wurde. Zur Vereinfachung des Unterstützungsprozesses sollten Sie eine von IBM bereitgestellte JVM verwenden. Andere JVM-Implementierungen verwenden einen anderen ORB. Der IBM ORB wird nur mit IBM Java Virtual Machines bereitgestellt. WebSphere eXtreme Scale erfordert für den Betrieb einen funktionierenden ORB. Sie können WebSphere eXtreme Scale mit ORBs anderer Anbieter verwenden. Tritt jedoch ein Problem mit diesem ORB auf, müssen Sie sich an den Anbieter dieses ORB wenden, um Unterstützung zu erhalten. Die IBM ORB-Implementierung ist mit JVMs anderer Anbieter kompatibel und kann bei Bedarf ersetzt werden.

Optimierung der Datei "orb.properties"

IBM hat für Tests die folgende Datei für Datengrids mit bis zu 1500 JVMs verwendet. Die Datei orb.properties befindet sich im Ordner lib der Laufzeitumgebung.
# Eigenschaften des IBM JDK für den ORB
org.omg.CORBA.ORBClass=com.ibm.CORBA.iiop.ORB
org.omg.CORBA.ORBSingletonClass=com.ibm.rmi.corba.ORBSingleton

# WS-Interceptor
org.omg.PortableInterceptor.ORBInitializerClass.com.ibm.ws.objectgrid.corba.ObjectGridInitializer

# Eigenschaften des WS-ORB und der Plug-ins
com.ibm.CORBA.ForceTunnel=never
com.ibm.CORBA.RequestTimeout=10
com.ibm.CORBA.ConnectTimeout=10

# Erforderlich, wenn sehr viele JVMs gleichzeitig eine Verbindung zum Katalog herstellen
com.ibm.CORBA.ServerSocketQueueDepth=2048

# Clients und Katalogserver können offene Sockets zu allen JVMs haben
com.ibm.CORBA.MaxOpenConnections=1016

# Thread-Pool für die Verarbeitung eingehender Anforderungen, hier 200 Threads
com.ibm.CORBA.ThreadPool.IsGrowable=false
com.ibm.CORBA.ThreadPool.MaximumSize=200
com.ibm.CORBA.ThreadPool.MinimumSize=200
com.ibm.CORBA.ThreadPool.InactivityTimeout=180000

# Keine Aufteilung großer Anforderungen/Antworten in kleinere Blöcke
com.ibm.CORBA.FragmentSize=0