Für Performance Untersuchungen ist es natürlich von großer Bedeutung, dass SAP Speichermodell vor Augen zu haben. Nur dann ist eine entsprechende Einordnung der SAP Parameter und der gemessenen Werte aus den entsprechenden Transaktionen möglich. Zur Veranschaulichung soll dieser Beitrag dienen, der das SAP Speichermodell in Windows Umgebungen darstellt.

FLAT Memory Model

Memory Management Windows / SAP => Kernel 7.00

Das Flat-Speichermodell wird mit dem 64-Bit-Windows zur Verfügung gestellt. Dieses Modell benötigt weniger CPU, aber mehr Speicherplatz.
Es wird mit dem folgenden Profilparameter aktiviert:
     es/implementation = flat
Mit dem Flat-Speichermodell werden alle Benutzerkontexte dauerhaft in allen Workprozessen zugeordnet. Ressourcenintensive Aufrufe, die ein Prozess-Working-Set modifizieren, werden nicht ausgeführt und proaktives Auslagern tritt ebenfalls nicht auf.
Dieses Verhalten wird als sehr positiv gewertet, solange die Kontexte in den physischen Speicher passen. Sobald die größer werdenden Prozess-Working-Sets durch das Betriebssystem beschränkt werden, könnte der Seitenwechsel die Performance sehr beeinträchtigen, da das Betriebssystem zwischen den verwendeten und nicht verwendeten Kontexten nicht unterscheiden kann.

Die Kontexte, die am längsten im System sind, werden als erstes ausgelagert. Wie viel Speicher zusätzlich benötigt wird, ist benutzerspezifisch und hängt davon ab, wie lange und wie viele Benutzer inaktiv sind. SAP rechnet zunächst mit über 30 % mehr physischen Speicher.

Mit dem Seitenschutz wird sichergestellt, dass die verschiedenen Benutzerkontexte vor Missbrauch in anderen Kontexten geschützt sind. Die Seiten, die zum aktuell ausgeführten Benutzerkontext gehören, zählen allerdings nicht dazu. Windows erzeugt einen beträchtlichen Overhead an CPU-Verbrauch beim Schützen der Seiten. Um wirklich vom Flat- Speichermodell zu profitieren, können der Speicherschutz mit dem folgenden Parameter deaktiviert werden:
     es/use_mprotect = false

Dies ist nicht für Produktiv-Systeme empfohlen, da der SAP Support ein geschütztes Speichermodell benötigt. Wird der Speicherschutz deaktiviert und treten Probleme auf, die sich auf überschriebene Speicherbereiche beziehen, kann der SAP Support die Ursache nicht im Detail analysieren.
Ein typisches Szenario für das ungeschützte Flat-Speichermodell ist die Operation in einer virtualisierten Umgebung. Da die Performance der virtualisierten Umgebung sehr sensibel auf die Anzahl der Systemaufrufe reagiert, reduziert das ungeschützte Flat- Speichermodell das Laden auf ESX beträchtlich.

Zero Management Model

Memory Management Windows / SAP < Kernel 7.00

Das klassische SAP-Speichermodell auf Microsoft Windows wurde für die 32-Bit-Adressierung entwickelt. Der gesamte Speicher, der für die ABAP-Transaktion benötigt wird (“Benutzerkontext”), wird in einer memory mapped file gespeichert. Der Benutzerkontext wird einem Workprozess beigefügt, wenn die Transaktion ausgeführt wird, und am Ende der Transaktion entkoppelt, wenn die Ausgabe an die Benutzeroberfläche gesendet wird.

Im Folgenden werden die Vorteile des klassischen Modells erläutert:

• Jeder Benutzer kann den Adressbereich des Prozesses vollkommen ausnutzen. Hierbei wird jedoch vorausgesetzt, dass der maximale Benutzeradressbereich 3 GB beträgt und Sie noch Speicherplatz für das Coding und die Shared Buffer reservieren müssen. Außerdem haben Sie ca. 2 GB für den Benutzerkontext zur Verfügung.
• Ausschließlich die regelmäßig verwendeten Kontexte verbleiben im Speicher. Das Windows-Betriebssystem verschiebt die Seiten, die von einem Prozess entkoppelt wurden, in die modifizierte Seitenliste. Die ältesten Seiten dieser Liste werden ausgelagert.

Der Nachteil des klassischen Modells besteht darin, dass die Betriebssystemaufrufe wie z. B. MapViewOfFile() sehr ressourcenintensiv sind, da die Prozessseitentabelle neu organisiert werden muss. Dieser Vorgang beansprucht außerdem einen kritischen Bereich innerhalb von Windows, in dem die Prozesse insbesondere auf den Multi-CPU-Servern serialisieren könnten.

Weitere Informationen über die verschiedenen SAP Speichermodelle auf Windows Betriebssystemen enthält der SAP Hinweis # 1002587 – Flat-Speichermodell auf Windows
und der SAP Hinweis # 88416 – Zero Administration Memory Management ab 4.0A/ Windows.

SAP Transaktionen für die technische Analyse

SAP Transaktionen für die Workload Analyse

In diesem Beitrag geht es um die ersten Schritte zur Performance Analyse in einem BW System. Vieles kann natürlich auch für ERP Systeme betrachtet werden.

Performance Engpässe in einem SAP BW System liegen aus meiner technischen Sicht natürlich eher in der Applikation Um das der Anwendungsbetreuung auch zu dokumentieren, können die folgenden Schritte hilfreich sein.

Zuerst schauen wir in der st03n

Hier sind folgende Aspekte zu beachten:

• Proc. Time ist eine berechnete Zeit
• RFC ist wichtig für BEx Queries
• Wenn Proc. Time = ein Vielfaches der CPU, dann deutet das auf einen CPU Engpass hin
• Die mittlere Wartezeit sollte zwischen 1 und 10 % der durchschnittlichen Antwortzeit betragen => sonst liegt ein allgemeines Performance Problem vor. Ausgelöst eventuell durch nicht genügend Workprozesse. Für den Anwender bedeutet das lang laufende Transaktionen
• Die mittlere DB Zeit sollte nicht mehr als 40 – 45 % der Antwortzeit betragen. Alles andere könnte seine Ursache in DB Problemen (z.B. auch CPU Engpass auf dem DB Server) oder Netzwerkproblemen (zwischen Appl. Und DB Server) haben
• GUI Zeit sollte bei < 250 ms liegen => sonst NW Engpass oder Probleme auf dem Präsentationsserver

   

  

• In diesem Beispiel ist die Durchschnittliche Wartezeit kleiner als 50 ms, damit liegt kein allgemeines HW Problem bezüglich der Performance vor.

• Tauchen in den Hitlisten (Ranking List) SAPMHTTP Aufrufe auf, so können das BW Queries sein
• Wenn man dann einen Doppelklick auf einen Eintrag macht, dann bekommt man die alle Zeiten zu dem Workprozeß angezeigt:

^

• Hier schaut man auch wieder auf die durchschnittliche Wait Time, ist diese zu hoch, stehen nicht genügend Ressourcen zur Verfügung (CPU)

Diese Übersicht könnte der erste Schritt sein, wenn Performance Engpässe in einem BW System auftauchen.

Natürlich gibt es noch viele weitere Aspekte, z.B. Einstellungen auf dem DB Server, Performance Aspekte innerhalb der DB etc.. Auf diese werde ich in weiteren Beiträgen eingehen.