Es gibt eine Kategorie von SAP Performance Problemen, die in HANA Metriken nicht sichtbar wird. Der HANA Speicher liegt im normalen Bereich. Die Antwortzeiten der Datenbank sind unauffällig. Die CPU auf dem Datenbank Host zeigt keine Besonderheiten. Und trotzdem melden Benutzer auf einer bestimmten Applikationsserver Instanz sporadische Verlangsamungen, die kommen und gehen, ohne dass ein klarer Zusammenhang zur Systemlast erkennbar ist.
Die Ursache liegt meist in der NetWeaver Schicht, genauer gesagt in der ABAP Speicherverwaltungsarchitektur, die zwischen Benutzern und Datenbank sitzt. Ausgelastetes Extended Memory, überlastete Roll Areas, verschlechterte Buffer Hit Ratios oder synchrone RFC Aufrufe, die Dialog Work Processes in einem Wartezustand halten, während die Antwort über einen Netzwerk Hop zurückkommt: All das erzeugt keine HANA Alerts. Es erzeugt Spitzen in der Dialogantwortzeit, die ohne ein Monitoring der Applikationsschicht nur schwer zuzuordnen sind.
Dieser Artikel behandelt die NetWeaver und ABAP Metriken, die Performance Stabilität in einer produktiven SAP Umgebung definieren. Der Fokus liegt auf Signalen, die sich klar vom Datenbank Monitoring unterscheiden, also auf den Metriken, die Performance Probleme erklären, die Datenbank Metriken strukturell nicht erklären können.
Die NetWeaver Performance Schicht, die viele Monitoring Ansätze übersehen
ABAP Speicherverwaltung ist nicht die Datenbankschicht
SAP NetWeaver ABAP verfügt über eine eigene Speicherverwaltungsarchitektur, die unabhängig von der zugrunde liegenden Datenbank arbeitet. Wer die zugehörigen Performance Metriken verstehen will, muss diese Architektur zuerst verstehen.
Jede Benutzersitzung in einem ABAP System verwaltet eine Roll Area: ein Speichersegment, das den Sitzungskontext zwischen Dialogschritten hält. Wenn ein Benutzer Enter drückt, speichert der Work Process, der diesen Schritt verarbeitet, den Sitzungszustand am Ende des Schritts in der Roll Area und stellt ihn zu Beginn des nächsten Schritts wieder aus der Roll Area her. Die Roll Area selbst wird aus dem Extended Memory, kurz EM, allokiert, einem Shared Memory Segment auf jeder Applikationsserver Instanz. Die Größe des Extended Memory wird über einen Profilparameter, abap/em_global_area_MB, auf Instanzebene konfiguriert.
Wenn das Extended Memory über aktive Sitzungen hinweg vollständig allokiert ist, können neue Sitzungen oder neue Dialogschritte keinen EM Speicher mehr beanspruchen. Sie weichen auf den prozesslokalen Heap aus, begrenzt durch die Profilkonfiguration, und schließlich auf die Roll Datei auf der Festplatte, was praktisch Paging bedeutet. Ein Dialogschritt, der festplattenbasierten Roll Speicher benötigt, dauert um Größenordnungen länger als ein Schritt, der aus Shared Memory bedient wird. Das geschieht transparent, ohne sichtbaren Fehler, und der Performance Effekt erscheint als sporadische Spitze in der Dialogantwortzeit, die bestimmte Benutzer betrifft und nicht das gesamte System.
Die Metrik, die diesen Zustand sichtbar macht, ist die Extended Memory Auslastung als Prozentsatz des konfigurierten Limits. Sie ist im ABAP Memory Monitor, Transaktion ST02, und in den Workload Statistiken verfügbar. In Standard Monitoring Konfigurationen ist sie selten enthalten, da diese meist auf Datenbank und Infrastruktur Metriken fokussieren und weniger auf Speicherkennzahlen der ABAP Schicht.
Warum sporadische Langsamkeit oft ein NetWeaver Problem ist und kein HANA Problem
Das Muster, das eine Untersuchung auf NetWeaver Ebene statt auf Datenbankebene auslösen sollte, hat klare Merkmale. Langsamkeit, die sitzungsspezifisch und nicht systemweit ist und verschwindet, wenn ein Benutzer sich abmeldet und erneut anmeldet, weist auf einen sitzungsbezogenen Speicherzustand hin. Langsamkeit, die ab einer bestimmten Anzahl gleichzeitiger Benutzer auftritt und nach dem Ende von Sitzungen wieder zurückgeht, deutet auf Druck im Extended Memory hin. Langsamkeit, die auf einer Applikationsserver Instanz konstant auftritt und auf anderen Instanzen derselben Landschaft fehlt, weist auf eine instanzspezifische Konfiguration oder Lastverteilung hin.
Keines dieser Muster erzeugt klare Signale im Datenbank Monitoring. HANA verarbeitet Abfragen mit normaler Latenz. Der Datenbank Host verfügt über freie CPU Kapazität. Das Monitoring Dashboard ist grün. Der Benutzer erlebt trotzdem Dialogschritte von 8 Sekunden. Die Erklärung liegt in der ABAP Schicht, nicht in der Datenbank.
Diese Lücke zwischen dem, was Datenbank Monitoring zeigt, und dem, was Benutzer erleben, ist der Grund, warum NetWeaver spezifische Metriken als eigener Monitoring Bereich gepflegt werden sollten. Sie beantworten Fragen, die Datenbank Metriken strukturell nicht beantworten können.
Die Metriken, die NetWeaver Performance Health definieren
Aufschlüsselung der Dialogantwortzeit: das echte Bild hinter der Gesamtdauer
Die gesamte Dialogantwortzeit ist als Trendmetrik nützlich, aber als Diagnosemetrik schwach. Eine Gesamtantwortzeit von 3 Sekunden kann bedeuten, dass 2,8 Sekunden auf Datenbankzeit und 0,2 Sekunden auf ABAP Verarbeitung entfallen. Sie kann aber auch bedeuten, dass 2,8 Sekunden RFC Wartezeit entstehen, während ein synchroner Aufruf an ein externes System abgeschlossen wird. Oder sie kann 2,8 Sekunden Wartezeit in der Queue bedeuten, bis ein Work Process verfügbar ist. Jeder dieser Fälle hat eine andere Root Cause und eine andere Lösung.
Der Workload Monitor, Transaktion SWNC oder /SDF/MON in älteren Systemen, erreichbar über SM66 in der Performance Analyseansicht, zerlegt die Gesamtantwortzeit in Komponenten: Verarbeitungszeit, also reine ABAP CPU Zeit, Datenbankanfragezeit, Roll und Dequeue Zeit für das Speichern und Wiederherstellen des Kontexts an Schrittgrenzen, Wartezeit in der Work Process Queue vor Beginn der Verarbeitung sowie RFC Zeit für synchrone Remote Function Calls an andere Systeme.
Jede Komponente getrennt zu überwachen und Alerts auf Anomalien einzelner Komponenten statt nur auf die Gesamtzeit auszulösen, macht Response Time Monitoring erst handlungsfähig. Ein Anstieg der RFC Zeit, der mit der Einführung einer neuen Schnittstelle zusammenfällt, weist auf ein Integrations Performance Problem hin. Ein Anstieg der Wartezeit, der mit einer höheren Anzahl gleichzeitiger Benutzer korreliert, weist auf ein Kapazitätsproblem bei den Work Processes hin. Ein Anstieg der Datenbankanfragezeit ohne entsprechende Änderung in HANA Metriken deutet auf fehlende Tabellenstatistiken oder eine Regression im Query Plan hin. Die Gesamtzeit verdeckt alle drei Ursachen. Die Komponenten machen sie sichtbar.
In der Praxis: Die Ansicht der statistischen Sätze in STAD liefert Antwortzeit Aufschlüsselungen auf Ebene einzelner Transaktionen. Wenn ein bestimmter Benutzer eine langsame Transaktion meldet, zeigt STAD, ob die Zeit in ABAP, in der Datenbank, in einem RFC Aufruf oder beim Warten auf einen Work Process verbracht wurde. Dadurch entstehen die Fakten, die eine Untersuchung gezielt ausrichten, statt mit Vermutungen zu beginnen.
Extended Memory Auslastung: die Metrik, die sporadische Langsamkeit erklärt
Extended Memory wird einmal auf Ebene des Instanzprofils konfiguriert und während des Betriebs nicht automatisch angepasst. Das gesamte verfügbare EM wird von allen aktiven Sitzungen einer Instanz gemeinsam genutzt. Jede Sitzung beansprucht bei der Anmeldung einen Anteil und gibt ihn bei der Abmeldung wieder frei. Sitzungen mit speicherintensiven Aktivitäten, großen Reports oder großen internen Tabellen im Sitzungskontext beanspruchen mehr als der Durchschnitt.
Der praktische Schwellenwert für die Extended Memory Auslastung liegt bei 80 % des konfigurierten Limits. Darunter gibt es genug Spielraum, damit gelegentliche Spitzen im Speicherverbrauch einzelner Sitzungen keine Sitzung zum Rollen zwingen. Oberhalb von 80 % kann eine einzige Sitzung, die aufgrund eines ungewöhnlich großen Abfrageergebnisses mehr EM als üblich benötigt, die Gesamtauslastung über das Limit drücken und andere Sitzungen in die Roll Datei zwingen.
Zwei Werte sind relevant: die aktuelle EM Auslastung als Prozentsatz des Limits und die maximale EM Auslastung der letzten 24 Stunden. Das Maximum erfasst Lastspitzen, die die aktuelle Auslastung verpasst. Eine Instanz mit 55 % aktueller EM Auslastung, deren Tagesmaximum aber 88 % erreicht hat, hat ein echtes Risiko, auch wenn sie zum Messzeitpunkt unkritisch aussieht.
Wenn die EM Auslastung dauerhaft hoch ist, gibt es mehrere Maßnahmen: das konfigurierte EM Limit im Instanzprofil erhöhen, was einen Neustart erfordert, die Anzahl gleichzeitiger Sitzungen auf der Instanz durch Änderungen in der Lastverteilung reduzieren oder Programme identifizieren und korrigieren, die übermäßig viel Sitzungsspeicher halten. Das wird typischerweise mit den Speicheranalyse Tools in der ABAP Workbench diagnostiziert.
Buffer Qualität: Table Buffer und Program Buffer Hit Ratios
SAP NetWeaver verwaltet mehrere In Memory Buffer Schichten auf jeder Applikationsserver Instanz, getrennt vom HANA Speicher. Zwei davon haben in den meisten Produktivumgebungen direkten Performance Einfluss: der Table Buffer und der Program Buffer.
Der Table Buffer speichert häufig gelesene Datenbanktabelleninhalte im Shared Memory des Applikationsservers. Tabellen, die für Buffering konfiguriert sind, etwa über SE13, werden aus diesem lokalen Cache statt aus der Datenbank gelesen. Für Customizing Tabellen, Konfigurationstabellen und häufig gelesene Stammdatentabellen vermeidet das Datenbankzugriffe, die sonst tausende Male pro Stunde stattfinden würden. Eine Table Buffer Hit Ratio unter 98 % bedeutet, dass mindestens 2 % der Reads auf gepufferte Tabellen an die Datenbank gehen, weil der Buffer zu klein ist, um das gesamte Working Set zu halten. In einem System mit hoher Customizing Leseaktivität erzeugt das messbare und unnötige Datenbanklast.
Der Program Buffer speichert kompilierte ABAP Programme im Shared Memory, sodass sie nicht bei jeder Ausführung erneut aus der Datenbank geladen werden müssen. Ein zu kleiner oder zu fragmentierter Program Buffer verursacht häufige Programm Reloads. Das sind teure Operationen, die über den Program Loader serialisiert werden und kurze, aber messbare Pausen erzeugen. Hit Ratios unter 95 % sollten in Produktivsystemen untersucht werden.
Beide Buffer Hit Ratios sind in ST02, dem ABAP Buffer Monitoring, sichtbar. Für die Diagnose zählt nicht nur die aktuelle Hit Ratio, sondern auch die Swap Anzahl: Wie oft wurden Buffer Objekte entfernt, um Platz für neue Objekte zu schaffen? Ein Buffer mit hoher Swap Anzahl ist im Verhältnis zur Vielfalt der geladenen Objekte unterdimensioniert, selbst wenn die Hit Ratio zu einem bestimmten Zeitpunkt akzeptabel aussieht.
Wichtig: Die Table Buffer Synchronisation über mehrere Applikationsserver Instanzen hinweg nutzt sogenannte Buffer Synchronization Messages. Wenn eine Customizing Tabelle auf einer Instanz geändert wird, invalidiert eine Synchronisationsnachricht die gecachte Version auf anderen Instanzen, damit diese aus der Datenbank neu geladen wird. In Systemen mit hoher Änderungsaktivität, etwa aktivem Customizing während der Geschäftszeiten, kann der Synchronisationsverkehr selbst kurze Performance Effekte verursachen. Das Monitoring der Buffer Synchronization Message Rate pro Instanz macht diesen Zustand sichtbar.
Short Dumps, Lock Entries und System Log als Performance Signale
Short Dump Rate als Stabilitätsindikator
Ein Short Dump, also ein ABAP Runtime Error, der in Transaktion ST22 erfasst wird, steht für einen Dialogschritt oder Background Job, der aufgrund einer unbehandelten Ausnahme abnormal beendet wurde. Die Ausnahme kann ein Programmfehler, ein Autorisierungsfehler, eine überschrittene Ressourcenlimite wie Memory Overflow oder Timeout oder eine Dateninkonsistenz sein, die das ABAP Programm nicht verarbeiten konnte.
In einem produktiven ABAP System sollte die Short Dump Rate nahe null liegen. Nicht, weil Fehler nie auftreten, sondern weil ein Produktivsystem ausreichend getestet sein und genügend Exception Handling besitzen sollte, damit Runtime Errors in benutzerrelevanten Transaktionen die Ausnahme bleiben und nicht zur Routine werden. Ein System mit durchschnittlich 15 Short Dumps pro Tag hat ein Stabilitätsproblem: Ein Teil der Benutzertransaktionen schlägt fehl, manche Background Jobs brechen ab, und die Ursache verschwindet in einer wachsenden ST22 Liste, statt verfolgt und behoben zu werden.
Short Dump Monitoring hat zwei Signale, die getrennt betrachtet werden sollten. Die absolute Anzahl pro Tag, die die allgemeine Stabilität zeigt, und die Verteilung nach Dump Klassen, die zeigt, welche Art von Problemen auftritt. MEMORY_NO_MORE_PAGING und TSV_TNEW_PAGE_ALLOC_FAILED sind speicherbezogene Dump Klassen, die anzeigen, dass Sitzungen ihre konfigurierten Speichergrenzen überschreiten. TIME_OUT zeigt Programme, die die maximale Dialogschrittzeit überschreiten. DBIF_REPO_SQL_ERROR weist auf Datenbankverbindungs oder Query Probleme hin. Jede Klasse zeigt auf eine andere Problemschicht.
Ansammlung von Lock Entries und ihre Performance Folgen
SAP ABAP Sperren werden vom Enqueue Work Process verwaltet und sind in SM12 sichtbar. In einem sauberen Produktivsystem ändert sich die SM12 Liste ständig, während Transaktionen während normaler Geschäftsabläufe Sperren setzen und freigeben. Einträge erscheinen kurz und verschwinden wieder, sobald Transaktionen committen.
Der Performance Zustand, auf den geachtet werden sollte, ist die Ansammlung von Lock Entries: eine wachsende Anzahl von Sperreinträgen auf bestimmten Objekten, die nicht freigegeben werden. Das passiert, wenn eine Transaktion eine Sperre setzt und nicht abgeschlossen wird, entweder weil ein Benutzer eine Transaktion gestartet und den Bildschirm offen gelassen hat, ohne sie zu beenden, oder weil ein Background Job eine Sperre über eine lange Verarbeitungssequenz ohne Zwischen Commits hält.
Angesammelte Sperren erzeugen einen versteckten Engpass. Jede nachfolgende Transaktion, die auf dasselbe Business Objekt zugreifen muss, wartet, bis die Sperre freigegeben wird. Benutzer erleben das als fehlende Reaktionsfähigkeit in bestimmten Transaktionen, ohne den offensichtlichen Zusammenhang zur gesperrten Sitzung an anderer Stelle im System zu sehen. Das Monitoring von Anzahl und Alter der SM12 Einträge, mit Alerts auf Einträge, die während der Geschäftszeiten länger als eine konfigurierte Dauer gehalten werden, macht diesen Zustand sichtbar, bevor daraus ein Incident entsteht.
Eine verwandte Metrik ist die Lock Table Auslastung: Der Enqueue Work Process verwaltet eine Sperrtabelle fester Größe. Wenn diese Sperrtabelle sich ihrer Kapazitätsgrenze nähert, werden neue Sperranfragen abgelehnt und Transaktionen schlagen mit einem Enqueue Fehler fehl. In Umgebungen mit vielen gleichzeitigen Benutzern oder lange gehaltenen Sperren kann diese Grenze gelegentlich erreicht werden. Das ist selten, verursacht aber klare Symptome, wenn es passiert, und sollte vom Monitoring erkannt werden, bevor Benutzer es bemerken.
SM21 und das System Log als Quelle für Performance Muster
Das SAP System Log, Transaktion SM21, erfasst systemnahe Ereignisse: Work Process Neustarts, Speichermangel, Roll File Overflows, Buffer Synchronization Events, ICM Fehler und Connection Pool Erschöpfung. Diese Ereignisse sind keine Performance Metriken im klassischen Sinn. Sie sind punktuelle Signale dafür, dass auf Systeminfrastrukturebene etwas Abnormales passiert ist.
Als Monitoring Quelle statt als manuelles Review Tool genutzt, liefert SM21 Kontext, den keine andere Metrikschicht bereitstellt. Ein Roll File Overflow Event in SM21 um 10:47 korreliert mit der Spitze in der Dialogantwortzeit, die im Workload Monitor um 10:47 sichtbar wurde. Ein in SM21 aufgezeichneter Work Process Neustart erklärt die kurze Unterbrechung der Dialogverfügbarkeit, die im Availability Monitoring erschien. Ohne SM21 Daten als Monitoring Quelle muss die Korrelation zwischen Infrastrukturereignissen und Performance Signalen jedes Mal manuell untersucht werden.
Die SM21 Ereignisklassen, die kontinuierlich überwacht werden sollten, sind Work Process Terminierungen und Neustarts, Roll Area Overflow Events, Extended Memory Overflow Events und Buffer Synchronization Fehler. Jede dieser Klassen weist bei einer Häufigkeit von mehr als ein oder zwei Ereignissen pro Stunde in Produktion auf einen systemischen Zustand hin, der untersucht werden sollte, statt nur Incident für Incident behandelt zu werden.
RFC Wartezeit: wenn Performance von einem anderen System abhängig ist
Synchrone RFC Aufrufe in Dialogschritten und ihre versteckten Kosten
Ein synchroner RFC Aufruf innerhalb eines Dialogschritts hält den Dialog Work Process für die gesamte Dauer des Aufrufs belegt, einschließlich Netzwerkzeit zum Zielsystem, Verarbeitungszeit auf dem Zielsystem und Netzwerkzeit für die Antwort. Der aufrufende Work Process kann in dieser Zeit keinen anderen Benutzer bedienen. Wenn das Zielsystem langsam ist, wird der aufrufende SAP Dialog Work Process dadurch ebenfalls langsam.
Dieser Performance Engpass wird häufig unterschätzt, weil Ursache und Symptom in unterschiedlichen Systemen liegen. Ein Benutzer meldet langsame Transaktionsperformance auf System A. Die Untersuchung zeigt, dass HANA gesund ist, Work Processes verfügbar sind und das ABAP Programm effizient ist. Was die Untersuchung übersehen kann: Das Programm führt einen synchronen RFC Aufruf an System B aus, um Daten abzurufen, und System B steht unter hoher Last mit 4 Sekunden Antwortzeit auf RFC Calls. Die Dialogantwortzeit von System A enthält diese 4 Sekunden Wartezeit auf die Antwort von System B, während System B in keinem Monitoring auftaucht, das nur auf System A fokussiert.
Die RFC Zeit Komponente in den ABAP Workload Statistiken ist die Metrik, die das sichtbar macht. Wenn RFC Zeit einen bedeutenden Anteil der gesamten Dialogantwortzeit ausmacht, liegt das Performance Problem im aufgerufenen System oder im Netzwerk dazwischen, nicht in der beobachteten SAP Applikationsschicht. Diese Unterscheidung lenkt die Untersuchung sofort in die richtige Richtung und verhindert, dass Zeit in die Optimierung des falschen Systems investiert wird.
RFC Call Chains und wie sich Wartezeit vervielfacht
Noch schwieriger wird es, wenn RFC Aufrufe verkettet sind. Transaktion X auf System A ruft Funktionsbaustein Y per RFC auf System B auf. System B ruft wiederum Funktionsbaustein Z per RFC auf System C auf, um zusätzliche Daten abzurufen, bevor es antwortet. Der Dialogschritt des Benutzers auf System A wartet auf den A zu B Round Trip, plus die Verarbeitungszeit von B, plus den B zu C Round Trip, plus die Verarbeitungszeit von C, plus die Rückgabe von C zu B, plus die Rückgabe von B zu A. Drei Netzwerk Hops und drei Verarbeitungszeiten werden in eine einzige Dialogantwortzeit serialisiert.
In komplexen SAP Landschaften mit mehreren angebundenen Systemen sind solche Ketten häufig und aus dem Monitoring eines einzelnen Systems oft unsichtbar. Erkannt werden sie entweder durch systemübergreifende RFC Performance Korrelation, bei der die RFC Wartezeit auf System A mit den realen Antwortzeiten auf System B und C korreliert wird, oder durch End to End Transaction Tracing, das die Aufrufkette über Systemgrenzen hinweg verfolgt.
Der praktische Startpunkt ohne systemübergreifendes Monitoring ist die Identifikation der RFC Destinationen, die den größten Anteil an der RFC Wartezeit in den Workload Statistiken verursachen. Eine einzelne RFC Destination, die 40 % der systemweiten RFC Wartezeit ausmacht, ist ein klares Ziel für eine Untersuchung auf Empfängerseite, unabhängig davon, wo die Symptome in der Dialogantwortzeit gemeldet werden.
Operation Modes und Lastverteilung über Instanzen
SM63 und das Dialog zu Background Verhältnis im Tagesverlauf
SAP Operation Modes, Transaktion SM63, ermöglichen es, das Verhältnis zwischen Dialog und Background Work Processes automatisch nach Tageszeit anzupassen. Eine typische Konfiguration nutzt während der Geschäftszeiten einen dialoglastigen Modus und wechselt nachts in einen backgroundlastigen Modus, wenn Batch Jobs laufen und keine interaktiven Benutzer aktiv sind.
Operation Mode Wechsel als Ereignisse zu überwachen, statt nur die Work Process Auslastung zu betrachten, liefert Kontext für die Interpretation von Auslastungsmetriken. Eine Spitze in der Work Process Auslastung, die genau zum Zeitpunkt eines Operation Mode Wechsels auftritt, ist kein Performance Incident. Sie ist das erwartete Verhalten während einer kurzen Rebalancing Phase. Eine Auslastungsspitze, die während eines geplanten Operation Mode Wechselzeitraums auftritt, aber deutlich länger anhält, als der Wechsel dauern sollte, kann darauf hinweisen, dass der Mode Switch nicht korrekt abgeschlossen wurde.
Das Konfigurationsrisiko bei Operation Modes entsteht, wenn das Batch Fenster mehr Background Work Processes benötigt, als der aktuelle Operation Mode bereitstellt, der Mode Switch aber nicht aktualisiert wurde, um Änderungen im Batch Schedule abzubilden. Die Batch Last ist gewachsen. Der Operation Mode weist weiterhin dieselbe Anzahl Background Work Processes zu wie vor zwei Jahren. Das Ergebnis ist ein Background Work Process Pool, der während des Nachtfensters saturiert, obwohl das System gut konfiguriert wirkt.
Lastverteilung über Instanzen: warum SM66 unverzichtbar wird
In einer Landschaft mit mehreren Applikationsserver Instanzen können Performance Probleme lokal auf einer Instanz auftreten, während andere Instanzen gesund sind. Logon Groups, Operation Modes und Background Job Server Group Zuweisungen beeinflussen, welche Benutzer und Jobs auf welcher Instanz landen. Wenn diese Verteilung unausgewogen ist, trägt eine Instanz überproportional viel Last, während andere unterausgelastet bleiben.
SM66 liefert die instanzübergreifende Sicht auf die Work Process Belegung. Monitoring Tools, die nur isolierte Pro Instanz Metriken melden, können das Muster übersehen, bei dem Instanz A dauerhaft bei 90 % Dialog Work Process Auslastung liegt, während Instanz B und C bei 40 % laufen. Der aggregierte Durchschnitt über alle drei Instanzen sieht moderat aus. Die Benutzer auf Instanz A erleben jedoch eine schlechtere Performance, als der Durchschnitt vermuten lässt.
Die erforderliche Monitoring Dimension ist eine getrennte Verfolgung der Work Process Auslastung pro Instanz, nicht eine Aggregation über die gesamte Landschaft. Ein Alert, der auslöst, wenn eine einzelne Instanz dauerhaft über 85 % Dialog WP Auslastung liegt, unabhängig davon, was auf anderen Instanzen passiert, erkennt das Ungleichgewicht. Ein Alert auf systemweiten Durchschnitt verfehlt es.
Eine wirklich nützliche NetWeaver Performance Baseline aufbauen
Eine NetWeaver Performance Baseline erfüllt einen anderen Zweck als eine HANA Performance Baseline. HANA Metriken haben relativ stabile Normalbereiche, die über Umgebungen mit ähnlichen Workload Profilen hinweg gelten können. NetWeaver Metriken sind stark von der Instanzkonfiguration und vom Verhalten der ABAP Programme abhängig, die auf dieser Instanz laufen.
Der normale Bereich für Extended Memory Auslastung hängt davon ab, wie viele gleichzeitige Sitzungen die Instanz typischerweise ausführt und wie speicherintensiv diese Sitzungen sind. Buffer Hit Ratios hängen davon ab, welche Tabellen gepuffert sind und ob der Buffer groß genug ist, um das Working Set zu halten. RFC Wartezeit hängt davon ab, welche externen Systeme aufgerufen werden und welche Antwortzeiten dort üblich sind. Für keine dieser Metriken gibt es universelle Normalwerte.
Eine nützliche NetWeaver Baseline entsteht durch die Erfassung von vier bis sechs Wochen Metriken über Geschäftstage hinweg, einschließlich der Unterschiede zwischen Montagsspitzen und Donnerstagnachmittagen, zwischen Monatsabschlussbeginn und einem normalen Dienstag in der Monatsmitte. Aus diesen Daten ergeben sich pro Metrik Normalbereiche, nicht als Einzelwerte, sondern als Verteilungen nach Tageszeit und Wochentag, die reale Betriebsmuster widerspiegeln.
Das praktische Ergebnis dieser Baseline ist eine Schwellenwertkonfiguration, die spezifisch genug ist, um handlungsfähig zu sein. Ein Alert auf Extended Memory Auslastung bei 80 % des Instanzlimits ist ein sinnvoller Hinweis, wenn die Baseline zeigt, dass der normale Peak bei 65 % liegt. Derselbe Alert bei 80 % auf einer Instanz, deren normaler Peak bei 78 % liegt, wird jeden Geschäftstag auslösen und innerhalb einer Woche ignoriert werden.
Eine Metrik sollte besonders in die Baseline aufgenommen werden, weil ihre Verschlechterung langsam und kumulativ ist: Buffer Swap Rates. Unter normalen Bedingungen sind die Swap Rates des Table Buffer und Program Buffer niedrig. Wenn die Trendlinie der Swap Rate über Monate hinweg allmählich steigt, wächst das Buffer Working Set, und die konfigurierte Buffer Größe wird irgendwann nicht mehr ausreichen. Diesen Trend in den Baseline Daten zu erkennen und die Buffer Konfiguration anzupassen, bevor Performance Degradation entsteht, ist genau die Art proaktiver Wartung, die Monitoring leisten soll.
Die Applikationsschicht zwischen Benutzern und Datenbank
NetWeaver und ABAP Metriken liegen in vielen SAP Umgebungen in einem Monitoring Blind Spot, weil sie zwischen zwei gut verstandenen Schichten sitzen. Infrastruktur und OS Monitoring decken den Server ab. Datenbank Monitoring deckt HANA ab. Die NetWeaver Schicht, mit eigener Speicherverwaltung, eigener Buffer Infrastruktur, eigener Work Process Planung und eigener Sperrverwaltung, liegt dazwischen und wird oft weniger konsequent überwacht als beide anderen Schichten.
Die daraus entstehenden Lücken sind vorhersehbar: sporadische Performance Verschlechterungen, die Datenbank Metriken nicht erklären, schlechter werdende Buffer Hit Ratios, die unnötige Datenbanklast erzeugen, synchrone RFC Ketten, die Performance Probleme über mehrere Systeme hinweg serialisieren, und wachsende Short Dump Bestände, die Stabilitätsprobleme anzeigen, die niemand untersucht, weil die Gesamtzahl nie alarmierend genug wirkte.
Keiner dieser Punkte erfordert besonders komplexe Tools. Entscheidend ist, die richtigen Metriken auf der richtigen Schicht zu erfassen und Baselines zu pflegen, die Abweichungen erkennbar machen. Der ABAP Workload Monitor, ST02, ST22, SM12 und SM21 enthalten die Daten. Die Frage ist, ob sie von der Monitoring Infrastruktur in einer Frequenz gelesen werden, die sie für Früherkennung nützlich macht, statt nur für Post Incident Untersuchungen.
Redpeaks überwacht SAP NetWeaver ABAP Umgebungen von der Applikationsschicht abwärts und deckt Extended Memory Auslastung, Buffer Hit Ratios, Antwortzeit Aufschlüsselung nach Komponenten, RFC Wartezeit pro Destination und Short Dump Trends ab. Keine Agents, keine Transports. Entdecken Sie die NetWeaver Monitoring Coverage.
