Einführung von Identifikatoren, Parameterauswertung und Speicherverbrauch

In dieser Lektion werden die Bedeutung der Instanz-ID und die Reihenfolge erläutert, in der das System Parameter auswertet und wo diese gespeichert werden.

Die Instanz-ID verstehen

Um die richtige Stelle zu finden, an der Sie mit der Konfiguration beginnen können, müssen Sie die Instanz-ID verstehen.

Jedes SAP-Java-System enthält die sogenannte Feldnummer, die sich aus drei Werten zusammensetzt: <SID> + <Instanznummer> + <Hostname>. Aus der Chiffrenummer wird dann die Java ID generiert.

Die obige Tabelle zeigt die Informationen zu jedem System und die von ihnen generierte ID, die auf Datenbankebene gespeichert wird.

Hinweis

Im Falle einer Inkonsistenz in der Feldnummer oder mit der Instanz-ID während einer Systemkopie bietet Software Provisioning Manager 1.0 SP10 und höher die Möglichkeit, sie in Ihrem System einfach zu korrigieren.

Reihenfolge der Parameterauswertung verstehen

SAP-Systeme können aus einer ASCS-Instanz und einer oder mehreren Anwendungsserverinstanzen bestehen. Wir konzentrieren uns hier auf Anwendungsserverinstanzen, da wir Serverhinweise konfigurieren möchten.

Eine SAP-Instanz wird mit einem Betriebssystembenutzer gestartet (Windows: SAPService<SID> oder Unix: sap<sid>). Die Umgebungsvariablen werden beim Starten einer SAP-Instanz ausgewertet.

Außerdem werden das SAP-Java-System und seine Instanzen durch Profilparameter konfiguriert, die in Profildateien wie SAP-ABAP-Systemen gespeichert sind. Sie unterscheiden zwischen dem Standardprofil und Instanzprofilen. Die Profile werden während der SAP-Installation generiert.

Bei der Konfiguration von Java-Server-Prozessen finden Sie in den Konfigurationswerkzeugen eine Vorlage, die in den benutzerdefinierten Abschnitten der Vorlage geändert werden kann.

Jede Instanz übergibt den Parameter an den Instanzstandard, der in den benutzerdefinierten Instanzabschnitten geändert werden kann.

Der größte Konfigurationsaufwand in Verbindung mit Java-Server-Prozessen entsteht auf der Ebene der Vorlage custom oder instance custom. Vielmehr werden in Ausnahmefällen Parameter in den Profilen hinterlegt.

Homogenität in einer Java-Instanz

Die Java-Instanz selbst ist homogen. Alle darin ausgeführten Serverprozesse verfügen über dieselben Komponenten, die auf jeder von ihnen implementiert sind. Außerdem haben sie die gleichen:

• Konfiguration: Alle Serverprozesse verwenden dieselbe Konfigurationsvorlage und teilen die benutzerdefinierten Einstellungen der Instanz.
• Lebenszyklus: Der Status aller Komponenten ist gleich. Wenn eine Komponente auf einem Serverprozess gestartet/gestoppt wird, wird sie auf allen Serverprozessen in der Java-Instanz gestartet/gestoppt. Um Homogenität zu gewährleisten, wird eine Komponente, die nicht auf einem Serverprozess gestartet werden kann, daher auf allen Serverprozessen gestoppt.

Im verwendeten Werkzeug unterscheidet sich die Darstellung der Vorlage custom und der instance custom.

In den folgenden Abschnitten werden einige Begriffe der Speicherverwaltung der SAP Java Virtual Machine (SAP JVM) in vereinfachter Form erläutert. Im Anschluss wird dann die Konfiguration der VM-Parameter besprochen.

Speicherbereich einer Java Virtual Machine (JVM oder VM) ist hauptsächlich in drei Bereiche unterteilt, die als Young Generation, Tenured Generation und Metaspace bezeichnet werden. Auf die Unterschiede der „generations" werden wir zu einem späteren Zeitpunkt etwas näher eingehen. Zunächst betrachten wir aber erstmal die Gemeinsamkeiten. Eine „generation" belegt Platz im Adressbereich des Rechners. Das Metaspace handhabt die Speicherverwaltung anders, das wird später noch besprochen.

Die Virtual Machine allokiert beim Starten für jede „generation" Speicher vom Betriebssystem. Jede „Generierung" hat eine initiale Größe und eine maximale Größe (maximale Größe). Beim Start allokiert die VM jedoch das Maximum des Speichers für jede „Generierung" aus dem Betriebssystem.

Zunächst verwendet die VM den Speicher der initialen Größe. Nach der Nutzung des initialen Speicherplatzes allokiert die VM stufenweise weiteren Speicherplatz bis zu einem Maximalbetrag. Es handelt sich um eine reine interne Allokation, der maximale Speicher wurde bereits beim Start vom Betriebssystem allokiert.

VM kümmert sich automatisch um die Zuweisung von Speicherplatz für Java-Anwendungen. Der Speicher wird implizit beim Anlegen eines Objekts zugeordnet. Selbst wenn viel Speicher gebraucht wird, bedeutet dies nicht, dass das System in Gefahr ist. Die VM bestimmt auch welche Objekte nicht mehr verwendet werden und gibt den von Ihnen verwendeteten Speicherbereich wieder frei. Dies ist die Aufgabe des Special Java Agent names Garbage Collector (GC) der Teil der VM ist. Dessen Aufgabe ist es zu verhindern, dass Situationen mit knappem Speicher auftreten.

Der Speicherplatz, der zur Verfügung steht, wird available memory oder auch allocated memory genannt. Da dieser Platz vom Betriebssystem reserviert ist, wird er auch „reserved" bzw. reservierter Platz genannt, da ja eigentlich der gesamte Platz bis zur Maximalgröße „verfügbar" ist. Der noch nicht reservierte Platz wird virtual memory genannt. Dies sollte aber nicht mit dem „virtual memory" des Betriebssystems verwechselt werden. Wird weniger Platz benötigt, erfolgt die Rückgabe an das Betriebssystem auch wieder schrittweise. Sehen Sie auch hierzu die Abbildung „Begriffe der Speicherplatzverwaltung"

Der reservierte Speicherplatz (available memory) steht der VM potentiell zur Verfügung. Er muss aber nicht komplett verwendet werden. Der Speicherplatz der von den Java-Applikation tatsächlich genutzt wird, wird als used memory bezeichnet.

Die drei Hauptspeicherbereiche der VM, die „Young, Tenured" und „Metaspace" unterscheiden sich aufgrund der darin gespeicherten Daten voneinander. In der young generation werden die von den Applikationen frisch erzeugten Objekte abgelegt. Objekte, die seit einer längeren Zeit von einer Applikation benötigt werden, werden automatisch in die tenured generation verschoben. In der „young generation" befinden sich die jüngeren Objekte und in der „tenured generation" die älteren Objekte. Objekte, die von der VM dauerhaft benötigt werden, wie Klassen und Methoden, werden im „Metaspace" abgelegt. Objekte, die von den Applikationen nicht mehr benötigt werden, werden automatisch aus den „generations" entfernt. Dieser Vorgang wird garbage collection genannt.

Wie Sie aus dem Unterabschnitt „Begriffe der Speicheraufteilung" bereits kennen, haben die „generation" eine initiale und eine maximale Größe. Bei der „young generation" lässt sich die „initial size" mit dem Parameter -XX:NewSize und die „max size" mit dem Parameter -XX:MaxNewSize festlegen. Die initiale und maximale Größe der „tenured generation" kann nicht direkt festgelegt werden. Sie ergibt sich indirekt aus den Parametern der „young generation" und den Parametern -Xmx und -Xms. Der Parameter -Xmx wird „max heap size" genannt und legt die Gesamtgröße von „young" und „tenured generation" fest. Der Parameter -Xms wird „start heap size" oder „initial heap size" genannt und legt die gesamte initiale Größe der „young" und „tenured generation" fest. Sehen Sie hierzu auch Abbildung „Speicheraufteilung der VM (vereinfacht)".

Das „Metaspace" hat ein anderes Verhalten als die Generationen. Beim Start allokieren die Generierungen den maximalen Speicher vom Betriebssystem. Der „Metaspace" hat nur den minimalen Speicher des Betriebssystems zugewiesen. Wenn der „Metaspace" also mehr Speicher benötigt, allokiert er mehr vom Betriebssystem. Durch dieses Verhalten kann der Metaspace wieder auf das Minimum zurückschrumpfen. Standardmäßig ist der Parameter -XX:MetaspaceSize nicht angegeben, daher wird der Standardwert von 21MB verwendet. Beim Start der JVM können die Garbage-Collections für den „Metaspace" mit der „Meldung perm gen low on memory" auftreten. Dies ist nicht kritisch und hat keine Auswirkungen auf die Performance, da diese Art von Garbage-Collections parallel zur Anwendung ausgeführt wird. Wenn Sie diese Meldungen jedoch während des Starts der JVM reduzieren, können Sie den Parameter -XX:MetaspaceSize auf „256m" setzen. In früheren Versionen der JVM gab es eine „Perm-Generierung" mit demselben Verhalten wie die „junge" oder „angehaltene Generierung". Diese „Perm-Generierung" wird durch den „Metaspace" ersetzt, auch wenn die Parameter für die „Perm-Generierung" noch in der Vorlage sichtbar sind, aber von der JVM ignoriert werden. Weitere Informationen finden Sie im SAP-Hinweis „2121243 - PermGen-Entfernung von SAP JVM."

Neben den Speicherplatz für die „generations" belegt die VM noch Platz für ihre Prozesse und Threads.

Nach dieser kurzen Einführung in die grundlegenden Begriffe der SAP JVM können wir uns nun der Konfiguration der VM-Parameter zuwenden.