1                     Themenübersicht

Comarch ERP Enterprise wurde mit der Programmiersprache „Java“ entwickelt. Deshalb wird die Hauptspeicherverwaltung zur Laufzeit eines ERP-System-Application-Servers (SAS) weitgehend durch die automatische „Garbage Collection“ (GC) der „Java Virtual Machine“ (JVM) übernommen.

Um einen leistungsfähigen Betrieb eines ERP-System-Application-Servers (SAS) zu ermöglichen, sind Parametereinstellungen für die „Java Virtual Machine“ notwendig, mit denen die „Garbage Collection“ beeinflusst werden kann. Bei den Parametereinstellungen ist die Häufigkeit des Auftretens von „Garbage Collections“ und der jeweiligen Dauer zur Durchführung der „Garbage Collection“ zu beachten.

In diesem Dokument werden die verwendeten Parameter für Comarch ERP Enterprise 5.4 vorgestellt und Richtwerte für unterschiedliche Anwendungs-szenarien gegeben.

2                     Zielgruppe

• Administratoren
• Technische Berater

3                     Systemvoraussetzungen

Die beschriebenen Parameter gelten für das „Oracle Java Development Kit“ (JDK) Version 1.8 bzw. die IBM-Java-Implementierung auf i5. Frühere JDK-Versionen werden nicht mehr unterstützt.

4                     Begriffsbestimmung

Hinweis:

Die folgenden Begriffsbestimmungen sind jeweils vereinfachte Definitionen. Zur genauen Definition lesen Sie bitte die Java- und Betriebssystem-Standard­literatur. Die Ausführungen gelten für die Oracle-Implementierung.
Concurrent User

„Concurrent User“ bezeichnet die Anzahl der gleichzeitig auf einem SAS aktiven, angemeldeten Benutze-Sessions. Diese Session-Anzahl hat nur indirekt mit der Anzahl der lizenzierten Benutzer zu tun, da jeder lizenzierte Benutzer mehrere Sessions (Login über eine Browser-Instanz) gestartet haben kann. Zu Concurrent Usern zählen auch Sessions des ERP-System-Output-Managers (SOM) bzw. auch Sessions für andere Services, wie Rechnungswesen- oder Business-Integration-Server (BIS).

Full Garbage Collection

Eine „Full Garbage Collection“ (FGC) führt neben dem Freigeben von Speicherplatz, auch ein Zusammenführen von freien Speicherbereichen zu größeren zusammenhängenden freien Speicherbereichen (Defragmentierung des Heaps) durch.

Garbage Collection

Der Vorgang, bei dem die JVM den nicht mehr von Objekten benötigten Speicher wieder als frei kennzeichnet, wird als „Garbage Collection“ (GC) bezeichnet. Nicht mehr benötigte Objekte (Müll) werden bildlich gesprochen eingesammelt und „weggeworfen“.

Heap

Der „Heap“ ist der Adressraum innerhalb des JVM-Prozesses, in dem Java-Objekte erzeugt und verwaltet werden. Weitere Informationen zum Aufbau des Heaps, erhalten Sie in der Oracle-Dokumentation zum Thema „Garbage Collection“.

Maximal adressierbarer Heap in einem 32-Bit-Betriebssystem

In jedem Betriebssystem kann ein Prozess nur eine theoretisch mögliche Obergrenze an Speicher adressieren. In einem 32-Bit-Betriebssystem sind das 4 GB, was 2³² Bit entspricht.

In der Praxis wird dieser Adressbereich von den Betriebssystemen noch einmal in jeweils 2-GB-große Adressbereiche unterteilt. Die eine Hälfte steht ausschließlich dem Betriebssystemteil des Prozesses zur Verfügung, die anderen 2 GB dem Benutzerteil des Prozesses. Zudem stehen auch diese 2 GB des Benutzerteils nicht vollständig zur Verfügung. Die Betriebssysteme blenden teilweise zur Ausführung der Programme notwendige DLLs oder „Libraries“ knapp jenseits von 1,5 GB in den Adressraum ein. Java setzt zur Adressierung einen durchgängigen Speicherbereich voraus und kann daher nicht mehr als ca. 1,5 GB Heap adressieren. Diese Anforderung an einen durchgängig adressierbaren, zusammenhängenden Adressbereich verhindert auch Methoden der Betriebssysteme, die Teile des verfügbaren Arbeitsspeichers durch „Paging“ einblenden und so manchen Anwendungen auch einen Benutzeradressraum von 3 GB „vorspielen“. Von Verfahren zur Änderung des Adressbereichs, in den Anwendungen, die DLLs und Libraries einblenden, wird abgeraten.

Neben dem Heap werden vom Prozess auch noch weitere Programmteile wie „Executables“ oder der benötigte Speicher für „Thread Stacks“ in diesen Benutzer-Adressbereich geladen. Da Comarch ERP Enterprise zur Laufzeit auch eine u. a. von der Verbindungsanzahl abhängige Anzahl Threads erzeugt, können auch die ca. 1512 MB nicht vollständig genutzt werden. Steht der JVM nicht mehr genügend Speicherplatz zur Verfügung, ob im Heap zur Erzeugung von neuen Objekten oder im restlichen Prozess zur Erzeugung neuer Betriebssystem-Threads, dann  stoppt die JVM die Ausführung des ERP-System-Appli­ca­tion-Servers (SAS) mit einem „Out of memory“-Fehler. Der Server ist „abgestürzt“ und der SAS muss neu gestartet werden.

Aus diesem Grund und aufgrund gestiegenen Speicherbedarfs wird der Betrieb eines SAS unter einer 32-Bit-JDK nicht mehr unterstützt. Ein Betrieb, z. B. im Entwicklungsbetrieb, ist dennoch generell möglich.

Metaspace

„Metaspace“ bezeichnet den Teil eines Heap, in dem die Klassen in den Hauptspeicher geladen werden.

Hinweis:

Metaspace ersetzt den „Permanent Generation Space“, der bis zum JDK 1.7 verwendet wurde.

New Generation

New Generation bezeichnet den Teil des Heap, in dem Speicherplatz für neue Objekte reserviert wird.

Old Generation

Old Generation bezeichnet den Teil des Heap, in den Objekte kopiert werden, die ein oder mehrere Garbage-Collection-Zyklen „überlebt“ haben.

Survivor Spaces

„Survivor Spaces“ sind ein von einigen Garbage-Collection-Algorithmen genutzter Speicherbereich, in den Objekte kopiert werden, wenn sie einige Male eine Garbage Collection „überleben“.

5                     Lebenszyklus eines Java-Objekts

Wenn durch den Programmcode ein neues Java-Objekt erzeugt wird, dann versucht die JVM den benötigten Platz für das Objekt auf dem New-Generation-Bereich des Heap zuzuteilen. Neue Objekte werden in diesem New-Generation-Bereich so lange erzeugt, bis nicht mehr genügend freier Platz zur Erzeugung eines neuen Objekts in diesem Teil des Heap zur Verfügung steht.

Wenn der Platz in dem New-Generation-Bereich zur Reservierung des benötigten Speichers für neue Objekte nicht mehr ausreicht, dann findet eine Garbage Collection statt. Diese räumt den New-Generation-Bereich auf. Der Speicherplatz nicht mehr benötigter Objekte wird freigegeben, Objekte auf die noch eine Referenz existiert, werden in die „Survivor Spaces“ oder den „Old-Genera­tion“-Bereich kopiert.

Wenn nun der Bereich der „Old Generation“ zu ca. 75 % gefüllt ist oder wenn dieser freie Speicherbereich kleiner ist als die Größe des New-Generation-Bereiches, dann wird eine „Full Garbage Collection“ auf dem Old-Generation-Bereich durchgeführt.

Die meisten während der Laufzeit eines SAS erzeugten Objekte sind nur Hilfsobjekte z. B. des JDBC-Treibers oder zur Berechnung der grafischen Oberfläche und haben eine sehr kurze Lebensdauer, da nach ihrer Nutzung keine Referenz mehr auf das Objekt besteht. Sie werden also nur in dem New-Generation-Bereich vorkommen.

Auf der anderen Seite existieren z. B. Stammdaten, die in den Caches gehalten und daher für die komplette Laufzeit des SAS referenziert werden. Diese Objekte landen auf dem Old-Generation-Bereich und werden nicht wieder aus dem Speicher entfernt. Auch ein z. B. mehrere Stunden angemeldeter Benutzer erzeugt Objekte, die dort „landen“.

6                     Memory Checker

In Comarch ERP Enterprise wird auf jeden Fall versucht ein Herunterfahren der JVM durch „Out Of Memory“-Fehler zu vermeiden, die auf zu wenig freien Heap-Speicher zurückzuführen sind.

In Comarch ERP Enterprise wacht der „Memory Checker Thread“ darüber, dass der freie Speicherplatz im Heap nicht ausgeht. Dazu wendet der „Memory Checker“ folgende Maßnahmen an: Falls der freie Speicher zu klein wird (weniger als 64 MB freier Speicher) erfolgt ein Speicherstufenwechsel von Zustand „Ok“ in Zustand „Warnung“. Eine „Full Garbage Collection“ wird aufgerufen, um Speicher freizugeben.

Wenn weiterhin versucht wird weiteren Speicher zu reservieren, dann werden von Comarch ERP Enterprise keine neuen Anmeldungen zugelassen. Als weitere Maßnahmen werden Anwendungen geschlossen, die sich im Anzeige-Modus befinden. Dadurch gehen keine eingegebenen Daten verloren. Falls alle Maßnahmen nicht greifen sollten, dann werden auch die angemeldeten Benutzer abgemeldet.

7                     Empfohlene JVM-Parameter

Die Java-JVM-Implementierungen der verschiedenen Hersteller unterscheiden sich teilweise grundlegend. In den folgenden Abschnitten werden für die unterstützten JVM-Implementierungen die zu verwendenden Parameter angegeben und erläutert.

7.1               Oracle-JVM-Implementierungen

Für jeden SAS kann im Systemcockpit ein eigener Satz JVM-Parameter hinterlegt werden. Diese hinterlegten Parameter werden während der Startsequenz des SAS ausgewertet und an die JVM weitergegeben.

Die Werte für JVM-Parameter können sich jederzeit und mit jeder JVM-Version ändern.

Die in Comarch ERP Enterprise 5.4 empfohlene Standard-JVM-Parameter­kombi­na­tion für SAS mit Oracle JVM auf JDK 1.8 lautet:

-server –Xms000m –Xmx000m

Der Speicherbereich für geladene Klassen wird ab dem JDK 1.8 intern anders verwaltet. Er trägt jetzt statt „Permanent Space“ die Bezeichnung „Metaspace“. Dementsprechend wird der Parameter -XX:MaxPermSize=000m nicht mehr unterstützt. Seine Angabe in der Kommandozeile führt zu einer Warnmeldung und der Wert wird ignoriert.

Parameterübersicht

7.2               IBM i5 JVM Implementierung

Die in Comarch ERP Enterprise 5.4 empfohlene Standard-JVM-Parameter­kombi­nation für i5 SAS lautet:

-Djava.version=1.8 –msNNNNm -mxNNNNm  -Djava.compiler=jitc-de
-Djava.awt.headless=true

Die angegebenen Werte werden im weiteren Verlauf näher erläutert. Manche der konkreten Zahlen, wie für die Größe des Heaps, müssen pro Installation angepasst werden. Hinweise, welche Größen Sie verwenden können, finden Sie in den Kapiteln Anwendungsszenarien und Besonderheiten der JVM-Versionen.

Die Werte für JVM-Parameter können sich jederzeit und mit jeder JVM-Version ändern.

Parameterübersicht

8                     Besonderheiten der JVM-Versionen

8.1               Oracle-Implementierung

Xms- und Xmx-Parameter

In der 64-Bit-Implementierung ist die Größe des Heaps nur durch die tatsächlich vorhandenen physikalischen Ressourcen wie Hauptspeicher und Festplatte (virtueller Speicher) beschränkt.

Verwenden Sie für den Xmx-Parameter

• Minimal 512 MB
• Für interaktive SAS bis zu 4 GB
• Für SAS zur Hintergrundverarbeitung theoretisch unbeschränkt, empfohlen werden jedoch bis zu 6 GB. Beachten Sie aber die entstehenden Garbage-Collection-Zeiten, die bei sehr großen Heaps zu Timeouts führen können.

8.2               64-Bit-IBM-i5-Implementierung

Die IBM-i5-Implementierung arbeitet im Gegensatz zu der Oracle-Implemen­tie­rung nicht mit generationenbasierten Algorithmen zur Durchführung der „Garbage Collection“. Dadurch ergeben sich unterschiedliche Parametersätze.

Viele der Parameter der Oracle-Implementierung stehen nicht zur Verfügung bzw. werden nicht benötigt.

Xms- und Xmx-Parameter

Die Größe des Heaps ist nur durch die tatsächlich vorhandenen physikalischen Ressourcen wie Hauptspeicher und Festplatte (virtueller Speicher) beschränkt.

Verwenden Sie für den Xmx-Parameter:

• Minimal 1 GB + Wert des Xms-Parameters
• Maximal die Speicherpoolgröße in GB – 2 GB für interne Verwaltungsinformationen

Setzen Sie den Xms-Parameter auf einen kleineren Wert wie den Xmx-Parameter:

• Minimal 0,5 GB

Die folgenden Einstellungen haben sich bewährt. Betreiben Sie die JVM jeweils in einem eigenen Subsystem und richten Sie möglichst einen eigenen Speicherpool für eine JVM ein.

Die Werte sind als Ausgangspunkte für weitere Optimierungen zu sehen.

9                     Anwendungsszenarien

Die angegebenen Werte in der folgenden Tabelle stellen lediglich erste Richtwerte dar. Die genauen Werte müssen im jeweiligen System durch das konkrete Lastprofil und Messungen ermittelt werden.

Hinweise:

• Beim Message-Server wird davon ausgegangen, dass keine Anmeldungen auf dem Message-Server stattfinden.
• Starten Sie einen eigenen SAS, in dem der Lagerlogistik-Server gestartet wird.
• Der PPS-Server bildet eine vollständige Repräsentation der zu verwaltenden Daten im Hauptspeicher ab. Die angegebenen Parameter für den Heap sind daher eher als Ausgangswert zu sehen. Je nach Datenmenge sind auch durchaus Werte von 6144 MB möglich.

10                Anmerkungen

Kopieren einer Datenbank

Damit Sie eine Datenbank kopieren können, benötigt der verwendete SAS mindestens 1024 MB Heap.

Größe des New-Generation-Bereiches

Bei der Definition der Größe des New-Generation-Bereiches müssen Sie zwischen Häufigkeit der „Garbage Collection“ und deren Dauer abwägen. Schnellere Prozessoren können in der Regel diesen Speicherbereich schneller bereinigen.

ODBC-Zugriffe benötigen Speicherplatz

Das Erzeugen von Berichten und Belegen erfordert ODBC-Zugriffe, um die Daten abzurufen. Diese Datenmengen können bei umfangreichen Berichten sehr groß werden und müssen damit in das Sizing des Heaps eingehen.

Application-Server-Cache

In diesem im Heap durch Comarch ERP Enterprise verwendete Speicherbereich werden Daten abgelegt, die für einen späteren Zugriff im Hauptspeicher gehalten werden sollen. Die Größe der Caches wird über die Anwendung „Application-Server-Einstellungen“ bestimmt. Dieser Speicherbereich wird, wenn er gefüllt wird, mit der Zeit in den Old-Generation-Bereich wandern. Da diese Daten in Comarch ERP Enterprise durch die Cache-Verwaltung verarbeitet werden, steht der belegte Speicher anderen Aufgaben nicht zur Verfügung, wie z. B. einer interaktiven Session.

Prüfen Sie regelmäßig den Füllgrad der SAS-Caches über die Anwendung „Systemcockpit“.

Der für den Cache benötigte Heap wird bei Bedarf bis zu seiner maximalen Größe erweitert. Solange der Cache nicht voll ist, steht der noch nicht belegte Speicherplatz des Caches anderen Aufgaben zur Verfügung.

Speicherverbrauch analysieren

Verwenden Sie z. B. das Tool „jconsole“, um sich die Speicherbelegung einer Oracle-JVM anzeigen zu lassen.

Verwenden Sie Werkzeuge wie „Memory Analyzer“ in Eclipse, um in einem Entwicklungssystem den Speicherverbrauch Ihrer Anwendungen genauer zu analysieren.