Die richtige Einstellung der SAP Speicherverwaltung ist nicht immer einfach. Zum einen kommt es auf die Anforderungen an das System an, zum anderen natürlich auf die vorgegebene Umgebung und verfügbare Ressourcen. Früher zunächst nur für die Windows-Systemschiene bei SAP verfügbar gibt es seit einiger Zeit das SAP Zero Administration Memory Management auch für Linux. Eine nette Sache! Richtig eingesetzt macht es gerade in virtuellen Umgebungen richtig Sinn. Den über einen prozentuale Angabe des zu benutzenden RAMs ist es möglich, dass das SAP System sich zum Großteil automatisch an die RAM Veränderung anpasst. Man gibt also der virtuellen Maschine mehr Arbeitsspeicher, startet die entsprechende Instanz durch und voilà – das System ist gleich passend für die wichtigsten Kenngrößen gesized ohne das auch nur an das Instanzprofil gedacht werden muss.
Wie geht man nun am Besten vor? Zunächst als <sid>adm ein cdpro absetzen um ins Profilverzeichnis (/sapmnt/<SID>/profile) zu wechseln und eine Sicherungskopie des aktuell aktiven Instanzprofils anlegen – safety first 🙂 Dreh- und Angelpunkt während der Anpassung ist der Parameter PHYS_MEMSIZE. Über diesen wird angegeben, wie viel Arbeitsspeicher für die Instanz genutzt werden soll. Die Angabe kann in Absoluten- und in Prozentwerten erfolgen. Somit kann man recht einfach für einen Application Server ohne Datenbank je nach Speicherausstattung 96 oder mehr Prozent angeben um dem Application Server möglichst viel Arbeitsspeicher zur Verwendung zu überlassen. Der Rest bleibt dann entsprechend für das OS übrig. In einer Shared Host Installation mit viel RAM kann so ggf. auch jeder Instanz 10% zugewiesen werden. Über das Konstrukt ist es dann ebenfalls möglich Instanzen mit hören Anforderungen über den Parameter gezielt mehr Speicher zuzuordnen ohne immer wieder an mehreren Parametern in mehreren Profilen schrauben zu müssen. Wird die Instanz auf dem Datenbankhost betrieben sollte hier zuvor genau errechnet werden wie viel Speicher das Datenbanksystem allein benötigt. In neueren SAP Releases geht das sehr einfach über die Transaktion DB02, die eine genaue Auflistung erstellt, die nicht nur die SGA enthält. Ansonsten muss man die Oracle Parameter auswerten und manuell errechnen.
Die für das jeweilige Kernelrelease unterstützen Formeln, die für das Memory Management herangezogen werden erhält man über sappfpar. Hierfür bietet sich folgendes Statement an:
sappfpar all | grep "SAP: ("
Der Befehl filtert alle Formeln heraus. Die Formeln werden alle geklammert und können daher über die Klammer schnell indentifiziert werden. Der Output sieht dann zum Beispiel so aus:
abap/buffersize = (ceil($(em/initial_size_MB)*1024*0.15/4096) * 4096) em/initial_size_MB = (min(512000, $(PHYS_MEMSIZE) * 0.7))
Die ausgegebene Liste ist natürlich um einiges länger als die beiden Beispielhaften Parameter hier. Die EM Initial Size wird also auf 70% der Größe von PHYS_MEMSIZE gesetzt. Der ABAP Program Buffer wird in Abhängigkeit von der EM Initial Size gesetzt. Die Formelparameter setzen oft Referenzen auf andere Parameter. Ich persönlich verkleinere die Formel für den ABAP Buffer generell, da er nach meiner Meinung viel zu groß gesetzt wird und trage das Ergebnis dann direkt ins Profil ein.
Es ist zwar möglich die SAP Standardformeln in das Profil einzutragen und diese auch zu verändern, jedoch gibt es dann ein Problem mit den Funktionsbausteinen, die die Profile einlesen bzw. checken. Das bedeutet, dass das System ganz normal startet (mit den gewünschten Werten aus den Formeln), jedoch alle Aktionen, die mit Profilprüfungen zusammenhängen nicht erfolgreich ausgeführt werden können und es zu einem Kurzdump vom Typ CONVT_NO_NUMBER, Ausnahme CX_SY_CONVERSION_NO_NUMBER, ABAP Programm SAPLSPFL, Anwendungskomponente BC-CCM-CNF-PFL kommt. Das nimmt der Lösung leider einiges an Flexibilität und Charme. Dieser Fehler wird ist erst in Netweaver Release 7.40 SP8 gefixt.
Angenommen ein Stand Alone Application Server mit Linux hat 128 GB Hauptspeicher und eine gesetzte PHYS_MEMSIZE von 96% so wird der ABAP Buffer auf > 15 GB gesetzt. Diese großen Werte werden meist nicht ausgenutzt. Selbst unter Netweaver 7.41 nicht, obwohl sich hier die Speicherverwaltung an vielen Stellen essentiell zum alten Netweaver 7.0 verändert hat.
Die Ausgabe des sappfpar kann man jetzt per vi oder sonstigem Editor in das Profil übernehmen und folgendem Kommando das Ergebnis prüfen:
sappfpar check pf=/sapmnt/<SID>/profile/<Instanzprofil>
Die Ausgabe zeigt die gesetzten Speicherparameter bzw. die ermittelten Werte, es werden Worst Case Speicherverbrauch sowie ggf. Warning oder Errors für unbekannte oder falsche Speicherparameter ausgegeben. Mit der Ausgabe kann man jetzt schauen ob die Werte passen oder ggf. nachgebessert werden muss. Sehr interessant ist auch zu sehen was passiert wenn die PHYS_MEMSIZE im Instanzprofil modifiziert wird. Die Änderungen werden direkt in entsprechende Werte umgesetzt. Besonderes Augenmerk sollte auf den Bereich mit der SWAP Informationen gelegt werden. Übertreibt man es mit den Speicherbereichen und Größen kann dies schnell zu hohen zusätzlichen SWAP Anforderungen bzw. intensiver Nutzung des SWAP führen. Das drückt dann je nach System und Auslastung natürlich die Performance des Application Servers unnötig in den Keller. Also hier besser zwei mal hingeschaut als hinterher in Hochlastsituationen das Nachsehen zu haben.
Mittels sappfpar lassen sich die Profile auch explizit auf die verwendeten Formeln bzw. Werte prüfen. Hierbei überprüft sappfpar die im Profil hinterlegten Formeln und gibt Auskunft darüber, ob ggf. ein Parameter mit einem absoluten Wert versehen ist, obwohl es eine entsprechende unterstütze Formel für den Parameter gibt:
sappfpar pf=/sapmnt/<SID>/profile/<Instanzprofil> check_formula
Wie schon geschrieben ist mir die von SAP angesetzte große des ABAP Buffers in Systemen mit viel RAM einfach zu groß ist. Da mit Kernel 7.40 der Rollspeicher weggefallen ist gibt es nur noch Formeln für den Page Speicher:
rdisp/PG_SHM = (max(min(1000+40*max(5,floor(($(PHYS_MEMSIZE)-128)*25/128)),16384),1024))
rdisp/PG_MAXFS
Die Werte von den Page reichen oftmals nicht aus und werden über die Formeln zu klein angesetzt. Hier hat es sich bewährt die Formel entsprechend nicht zu benutzen und gleich manuell größere Werte einzutragen um den Anforderungen an das System gerecht zu werden. Hier besonders wichtig und ganz oft übersehen der zugehörige Parameter rdisp/PG_MAXFS mit dem angegeben wird, wie viel des Page Speichers als Datei ins Filesystem ausgelagert werden soll. Das sollte man möglichst vermeiden, da die Auslagerung auf Disk natürlich enorme Performance-Einbußen mit sich bringt. Hier lieber die beiden Parameter exakt gleich setzen und somit dafür sorgen, dass der Page komplett im RAM gehalten wird. Natürlich sollte der Bereich nicht zu klein angesetzt werden. Auf keinen Fall sollte man auf die Idee kommen rdisp/PG_MAXFS oder rdisp/PG_SHM gar nicht in den Profilen zu setzen. Hier greift dann der Default und das bedeutet kleiner Bereich im RAM und zusätzlich noch ein kleiner Bereich in der dedizierten Page Datei. Die denkbar ungünstige Variante.
Die folgenden beispielhaften Fehlermeldungen (Dumps) deuten i.d.R. auf zu kleinen EM Speicherbereich hin:
- TSV_TNEW_PAGE_ALLOC
- LOAD_NO_ROLL
- STRING_LENGTH_TOO_LARGE
- TSV_TNEW_BLOCKS_NO_ROLL_MEMORY
Das mir bekannte Limit für PHYS_MEMSIZE liegt übrigens bei absoluten 512 GB. Falls es dann doch mal größer werden sollte müsste auf dem Server dann eine zweite Instanz installiert werden.
Bei einem Umstieg von Netwaver 7.0 auf 7.4x ist es wichtig die SAP Hinweise zum angepassten Speichermanagement und weiteren internen Anpassungen zu lesen, da ansonsten das 7.4x mit den alten Parametern in einer ungünstigen Konfiguration laufen kann oder ggf. alte Parameter noch unterstützt werden, sofern sie explizit im Profil gesetzt werden, jedoch dann neuere Mechanismen aushebeln. Hinweise hierzu gibt es im SAP Marketplace und unter help.sap.com (z.B. ztta*, task_limit, rdisp*quota*, …)
Wie immer gilt es gibt kein Patentrezept und solange das SAP System seine Speicherbereiche nicht alle dynamisch zur Laufzeit anpassen kann wird es das auch nicht geben. Die Standard Formeln, die SAP als Kernel Default ausliefert reichen in der Regel für Entwicklungssysteme und kleinere Produktionssysteme. Trotzdem sollte man sich nicht blind drauf verlassen, dass alles automatisch korrekt eingerichtet ist. Für lastintensive Systeme kommt man um ein individuelles Sizing nicht herum, um das Optimum aus den verfügbaren Ressourcen heraus zu kitzeln.
Beim Thema Performance gibt es immer wieder passend die Diskussion zum Paging des OS (früher „swappen“ genannt“). Natürlich ist es immer gut wenn man soviel RAM zur Verfügung hat, dass ein System nicht beginnen muss Speicherseiten ins Pagefile auszulagern. Das ist aber nur selten der Fall, sofern man den RAM eines Servers wirklich ausnutzen will. Solang sich das Paging im Rahmen hält ist es nicht kritisch und hat auch keine deutlich negativen Auswirkungen auf die gesamtperformance des Systems. Die paar Millisekunden mehr für den ein oder anderen Request gehen i.d.R. im Grundrauschen mit unter. Teilweise lässt es sich auch nicht verhindern wenn das OS inaktiven Speicher auslagert, der lange Zeit nicht mehr genutzt worden ist um für den Bedarfsfall freien Arbeitsreicher für Anfragen freizuhalten. Ein guter Indikator ist die Ausgabe von „memlimits“. Das Thema sollte jedoch nicht überstreust werden. Über die Transaktion ST06 hat man einen guten Langzeitüberblick über das Pageverhalten des Servers. Steigt die aktive Pagefilenutzung zu gewissen Zeiten immer wieder kurzeitig an sollte man das Verhalten längerfristig beobachten, da sich hier ein Performanceengpass ankündigen kann. Liegt die Nutzung konstant auf einem gleichbleibenden niedrigen Niveau (ca. 5-15%, natürlich je nach Pagegröße) kann man das Pagen in der Regel ignorieren und die Investition in mehr RAM noch verschieben.