Anforderungen an externen Application-Server

Ein externer Application-Server sollte in erster Linie einen unterbrechungsfreien Betrieb gewährleisten. Das bedeutet vor allem, eine vorausplanende Konfiguration der Java-VM bezüglich Heap-Größe und Garbage Collection vorzunehmen.

Für die Konfiguration der Java-VM eines externen Application-Servers gelten dieselben Vorgaben, wie beim FirstSpirit-Server (siehe Konfiguration der Java-VM):

Anpassen der Speicherverwaltung der Java VM

Heap

Der für FirstSpirit nutzbare Speicherbereich ist der sogenannte „Heap“ der Java-VM.

Ist der Heap zu gering eingestellt, kann die Java-VM nicht genug Arbeitsspeicher vom Betriebssystem abrufen und der FirstSpirit-Server kann Anfragen nicht mehr verarbeiten und reagiert mit Fehlermeldungen aufgrund von „unzureichendem Arbeitsspeicher“.

Der Heap sollte so groß wie möglich eingestellt werden, aber nicht größer als der im Betriebssystem freie Hauptspeicher sein.

Ein Heap wesentlich größer als 10 GByte kann mit den hier genannten Parametern nicht problemlos verwaltet werden. Falls diese Größenordnung notwendig ist, muss das Verhalten der Garbage-Collection über JMX mittels jconsole oder VisualVM analysiert und die Java-VM-Parameter an den Anwendungsfall im Detail angepasst werden.

Sofern ein Heap größer als 10 GByte eingestellt werden soll, muss zunächst beim Hersteller (Crownpeak Technology GmbH) angefragt werden, da in solchen Fällen meist weitere, spezielle Parameter zum Konfigurieren des Garbage Collectors notwendig sind.

Ein großer Java-Heap (über 1 GByte) erfordert eine Optimierung der Parameter zur Anpassung der Garbage Collection, die im folgenden Abschnitt beschrieben wird.

Initiale und maximale Heap-Größe konfigurieren

Der Parameter –Xms definiert die initiale Heap-Größe (entspricht dem Parameter wrapper.java.initmemory bzw. wrapper.java.initmemory.percent in der Konfigurations-Datei fs-wrapper.conf), die der Java-VM beim Starten zugeteilt wird (siehe Parameter des Java-Wrappers).

Der Parameter –Xmx definiert die maximale Heap-Größe (entspricht dem Parameter wrapper.java.maxmemory bzw. wrapper.java.maxmemory.percent in der Konfigurations-Datei fs-wrapper.conf), die der Java-VM zur Verfügung gestellt wird (siehe Parameter des Java-Wrappers).

Wenn die VM Speicher aus dem Speicher des Betriebssystems alloziert oder freigibt, kann das Verzögerungen verursachen. Das kann vermieden werden, wenn die initiale und die maximale Heap-Größe auf den gleichen Wert gesetzt werden, also z. B.:.

wrapper.java.initmemory=6000 
wrapper.java.maxmemory=6000

Der Heap sollte nicht unnötig groß gewählt werden, da FirstSpirit versucht, den gesamten freien Speicher als Cache zu belegen.

Der Parameter -Xmn sollten ab Java 9 nicht mehr verwendet werden, da er negative Auswirkungen auf die Garbage Collection G1 (Garbage-First) hat.

Monitoring der Heap-Auslastung

Die Parameter com.sun.management.jmxremote dient zum Monitoring der Heap-Auslastung, auch während des Produktionsbetriebs, so dass Trends bezüglich der Speicherbelegung erkannt werden können und bei Bedarf eine Vergrößerung der Heapsize erfolgen kann.

Aktuelle Monitoring-Systeme bieten eine JMX-Schnittstelle, um darüber Web-Application-Server überwachen zu können.

Zur Abfrage der aktuellen Werte ist die Web-Application „PSI Probe“ empfehlenswert (https://github.com/psi-probe/psi-probe).

Darüber hinaus kann das Programm jconsole zur interaktiven Abfrage verwendet werden. Es ist Bestandteil jedes JDK (nicht JRE) von Oracle.

Metaspace

Anpassen der Garbage Collection der Java-VM

Große Datenmengen in FirstSpirit-Projekten oder eine hohe Anzahl gleichzeitig aktiver FirstSpirit-Benutzer können den Garbage-Collector der Java-VM überlasten. Die Überlastung macht sich durch Wartezeiten im Bereich größer als 10s in der Antwortzeit der FirstSpirit-Clients bemerkbar. Bei längeren Wartezeiten können auch Verbindungsabbrüche zwischen FirstSpirit-Client und -Server auftreten. Die Ursache für die Wartezeit ist die Garbage-Collection, die den FirstSpirit-Server für bestimmte Operationen temporär vollständig anhält. Dieser Zustand wird als „Stop-The-World“ (STW) bezeichnet.  

In der Log-Datei des Garbage-Collectors (log/fs-wrapper.log bzw. log/fs-gc.log) ist zu diesem Zeitpunkt die Meldung „Full GC“ oder „time exceeded“ zu sehen.

FirstSpirit verwendet in der Standardkonfiguration den Garbage Collector G1 (Garbage-First). Der G1 Collector teilt unter anderem das Aufräumen der langlebigen Objekte („Old Generation“) in mehrere Teilbereiche auf, die nicht alle „Stop-The-World“ sein müssen. Das heißt, auch hohe Lasten (große Daten, viele Benutzer) sollten kaum Verbindungsabbrüche zwischen dem FirstSpirit-Server und den -Clients verursachen.

Sollten dennoch Probleme auftreten (Verbindungsabbrüche, lange Antwortzeiten, nicht genug Speicher), können die entsprechenden GC-Parameter zur Optimierung konfiguriert werden (siehe z. B. https://docs.oracle.com/en/java/javase/11/gctuning/garbage-first-garbage-collector-tuning.html#GUID-90E30ACA-8040-432E-B3A0-1E0440AB556A).

Im Einzelfall kann auch die Umstellung auf einen anderen GC-Collector helfen (siehe https://docs.oracle.com/en/java/javase/11/gctuning/available-collectors.html#GUID-F215A508-9E58-40B4-90A5-74E29BF3BD3C)

Generell gilt: Das Monitoring der Heap-Auslastung und der Garbage Collection ist unbedingt notwendig, um die individuell richtige Einstellung für die Heap-Größe und die GC-Parameter zu ermitteln.