Ein SAP Dialog Work Process Pool ist eine feste Ressource. Die Anzahl der Dialog Work Processes auf einer Application-Server-Instanz wird bei der Installation konfiguriert und ändert sich während des Betriebs nicht. Wenn alle belegt sind, erhält die nächste Nutzeranfrage keinen Thread aus einem dynamischen Pool und auch keinen neu erzeugten Prozess: Sie wartet. Sie bleibt in einer Warteschlange, bis einer der belegten Work Processes seine aktuelle Aufgabe beendet und wieder verfügbar wird.
Genau dieser architektonische Fakt macht das Monitoring von Work Processes anders als die meisten anderen Formen des SAP Performance Monitorings. Speicherdruck verschlechtert die Performance schrittweise. Datenbank-Contention verlangsamt einzelne Abfragen. Die Sättigung von Work Processes erzeugt eine wachsende Warteschlange, und Warteschlangen nahe einer festen Kapazitätsgrenze wachsen nicht linear. Bei 70 % Auslastung bleiben die Wartezeiten beherrschbar. Bei 85 % werden sie spürbar. Bei 95 % ist das System für neue Anfragen praktisch nicht mehr verfügbar, obwohl jeder Work Process technisch gesehen läuft.
Dieser Artikel erklärt, wie Work Processes so überwacht werden, dass Sättigung erkannt wird, bevor sie Nutzer erreicht, was die verschiedenen Work-Process-Typen tatsächlich tun und warum sie unterschiedlich ausfallen, was SM50 und SM66 wirklich zeigen, was viele Teams nicht richtig lesen, und worauf kontinuierliches Monitoring über die Momentaufnahmen dieser Transaktionen hinaus achten muss.
Wie Work Processes wirklich funktionieren und warum der feste Pool wichtig ist
Die Architektur hinter dem Engpass
Jede SAP NetWeaver ABAP Application-Server-Instanz hat eine feste Anzahl von Work Processes, die nach Typ aufgeteilt sind: Dialog (DIA), Background (BTC), Update (UPD und UPD2), Enqueue (ENQ), Spool (SPO) und Message (MSG). Die Konfiguration liegt im Instanzprofil. Eine Änderung erfordert einen Neustart.
Dialog Work Processes verarbeiten interaktive Nutzertransaktionen. Wenn ein Nutzer in einem Transaktionsbildschirm Enter drückt, belegt er einen Dialog Work Process für die Dauer dieses Bildverarbeitungsschritts, gibt ihn wieder frei, sobald der Bildschirm zurückgegeben wird, und belegt für den nächsten Schritt erneut einen. Jeder einzelne Interaktionsschritt wird typischerweise in Millisekunden bis Sekunden gemessen. Der Work Process wird nicht zwischen den Bildschirmen gehalten.
Dieses Design ermöglicht es dem System, deutlich mehr Nutzer zu bedienen, als es Work Processes besitzt, solange Nutzerinteraktionen kurz bleiben. Ein System mit 20 Dialog Work Processes kann problemlos 200 gleichzeitige Nutzer bedienen, wenn der durchschnittliche Dialogschritt 0,1 Sekunden dauert. Dasselbe System hat Schwierigkeiten mit 50 Nutzern, wenn ein Programm einen Dialog Work Process während einer lang laufenden Datenbankabfrage 90 Sekunden lang belegt.
Die Monitoring-Konsequenz ist: Die gefährliche Bedingung ist nicht die Anzahl der Nutzer. Entscheidend ist die Belegungsrate des Work Process Pools in Kombination mit der Dauer einzelner Schritte. Ein System, in dem 90 % der Dialog Work Processes genutzt werden, hat nur noch sehr wenig Spielraum, bevor neue Anfragen in die Warteschlange geraten. Und eine Warteschlange, die sich während einer Spitzenzeit bildet, selbst nur kurz, erzeugt für Nutzer das Gefühl, dass das System nicht mehr reagiert.
Was Nutzer erleben, wenn der Pool voll ist
Aus Nutzersicht sieht die Sättigung von Work Processes genauso aus wie eine langsame Datenbank oder ein langsames Netzwerk. Der Bildschirm hängt. Die Sanduhr dreht sich. Nichts passiert. Nutzer können nicht erkennen, ob ihre Anfrage langsam verarbeitet wird oder ob sie überhaupt erst auf Verarbeitung wartet.
Deshalb werden Work-Process-Engpässe häufig falsch diagnostiziert. Der Nutzer meldet, dass das System langsam ist. Der Basis Engineer prüft CPU und Speicher, findet nichts Auffälliges und schließt das Ticket als gelöst. Die eigentliche Ursache, eine vorübergehende Sättigung des Dialog Work Process Pools während eines konkreten 10-Minuten-Fensters, hinterlässt keine Spur in den Metriken, die geprüft wurden.
Um sie zu erkennen, braucht es Monitoring, das die Belegung von Work Processes über die Zeit aufzeichnet, nicht nur den aktuellen Zustand. Ein System, bei dem die Dialog Work Processes jeden Tag um 09:15 für 10 Minuten zu 95 % ausgelastet sind, hat ein echtes Betriebsproblem. Dieses Problem bleibt unsichtbar für jeden, der SM50 um 09:30 öffnet und eine gesunde Lastverteilung sieht.
Work-Process-Typen, die unterschiedlich überwacht werden sollten
Dialog Work Processes: Hier entsteht die Nutzererfahrung
Die Belegung der Dialog Work Processes ist die Metrik, die am direktesten mit nutzerseitig spürbarer Performance verbunden ist. Wenn sie dauerhaft über 80 % steigt, werden neue Anfragen in die Warteschlange gestellt. Die Antwortzeit, die Nutzer erleben, spiegelt dann nicht mehr nur die tatsächliche Verarbeitungszeit wider, sondern die Wartezeit in der Queue plus die Verarbeitungszeit, was ein Vielfaches betragen kann.
Die beiden Muster, die am häufigsten eine Dialog-Sättigung verursachen, sind nicht unbedingt diejenigen, die in SM50 besonders dramatisch aussehen. Das erste ist eine große Anzahl von Nutzern, die während eines Spitzenfensters normalerweise schnelle Transaktionen ausführen, wobei die kumulierte Last die Pool-Kapazität übersteigt. Das zweite ist eine kleine Anzahl von Nutzern, die Transaktionen mit unerwartet langen Dialogschritten ausführen: ein kundeneigener ABAP-Report mit vollständigem Tabellenscan, eine Preisfindung, die synchron einen externen Service aufruft, oder eine Berechtigungsprüfung, die auf ein überdimensioniertes Profil trifft.
Beide Muster erzeugen aus Nutzersicht dasselbe Symptom. Sie haben jedoch unterschiedliche Ursachen und unterschiedliche Gegenmaßnahmen. Das Monitoring muss sie unterscheiden können. Eine hohe Dialog-WP-Belegung bei normalen Antwortzeiten pro Schritt weist auf ein Kapazitätsproblem hin: zu viele Nutzer für die Poolgröße. Eine hohe Dialog-WP-Belegung bei erhöhten Antwortzeiten pro Schritt weist auf ein Programm-Performance-Problem hin: Etwas hält Work Processes länger, als es sollte.
Background Work Processes: Konkurrenz, die im Hintergrund entsteht
Background Work Processes führen Batch Jobs aus. Sie sind in der Konfiguration von Dialog Work Processes getrennt, laufen aber auf demselben Application Server und verbrauchen dieselbe CPU, denselben Speicher und dieselbe Datenbankverbindungskapazität. Ein Batch Job, der auf einem Application Server läuft, der gleichzeitig Dialognutzer bedient, erzeugt Ressourcenkonkurrenz, die Nutzer spüren, ohne die Ursache sehen zu können.
Das konkrete Problem ist eine Kollision in der Jobplanung: mehrere große Batch Jobs, die zur gleichen Zeit geplant sind, oder ein Batch Job, dessen Laufzeit im Laufe der Zeit gewachsen ist und nun das morgendliche Spitzenlastfenster überschneidet, das er früher rechtzeitig beendet hatte. Die Batch Jobs schlagen nicht fehl. Die Dialog-Antwortzeiten steigen. Die beiden Ereignisse wirken unabhängig voneinander, bis man sie auf einer Zeitachse korreliert.
Die Auslastung der Background Work Processes verdient eine eigene Monitoring-Spur, getrennt vom Dialog. Eine dauerhaft hohe Background-WP-Auslastung über 90 % während der Geschäftszeiten ist ein Planungsproblem. Sie bedeutet, dass der Batch-Plan während eines Zeitraums den gesamten Background-WP-Pool verbraucht, in dem verspätete oder länger laufende Jobs keinen freien Startpunkt finden, und in dem die Ressourcenkonkurrenz mit Dialog am höchsten ist.
Update Work Processes: Die Warteschlange, die niemand beobachtet, bis sie bricht
Update Work Processes verarbeiten asynchrone Datenbank-Updates. Wenn ein Nutzer eine Transaktion in SAP speichert, wird der Dialogschritt abgeschlossen und das eigentliche Datenbank-Update an einen Update Work Process übergeben. Der Nutzer sieht sofort die Bestätigung. Der physische Schreibvorgang erfolgt kurz danach im Hintergrund.
Dieses Design verbessert die Dialog-Antwortzeit, indem die nutzerseitige Interaktion vom Datenbank-Schreibvorgang entkoppelt wird. Die Folge ist, dass ein Problem mit einem Update Work Process nicht sofort einen nutzerseitig sichtbaren Fehler erzeugt. Der Nutzer hat erfolgreich gespeichert. Das Update befindet sich in der Warteschlange. Wenn Update Work Processes gesättigt sind oder eine Update-Aufgabe mit einem Fehler endet, bleibt das wartende Update in der SM13-Update-Queue als fehlgeschlagene Anfrage stehen. Daten, von denen der Nutzer glaubt, sie seien gespeichert, wurden nicht tatsächlich in die Datenbank geschrieben.
SM13 auf fehlgeschlagene Update-Anfragen zu überwachen, ist eine Monitoring-Anforderung, die häufig ausgelassen wird, weil Update-Fehler in stabilen Systemen selten sind. Wenn sie auftreten, haben sie eine hohe Kritikalität: Ein Geschäftsbeleg, den der Nutzer als gespeichert bestätigt bekommen hat, existiert nicht in der Datenbank. Der Nutzer hat möglicherweise bereits auf Basis der Annahme gehandelt, dass das Speichern erfolgreich war. Je länger die Lücke zwischen Fehler und Entdeckung ist, desto komplexer wird die Behebung.
Ein zusätzlicher Zustand sollte separat überwacht werden: Wenn der Update-Service selbst absichtlich oder versehentlich deaktiviert ist, sammeln sich alle ausstehenden Updates unbegrenzt in der Queue. Das System akzeptiert weiterhin Speichervorgänge von Nutzern und bestätigt sie. Nichts wird in die Datenbank geschrieben. Dieser Zustand ist über den Status des Update-Systems in SM13 erkennbar und sollte mit einem kritischen Alert überwacht werden, nicht mit einer Routineprüfung.
Achtung: Ein deaktivierter Update-Service ist einer der schwerwiegendsten SAP-Betriebszustände und einer der am leichtesten zu übersehenden, wenn kein dediziertes Monitoring vorhanden ist. Er kann durch eine administrative Aktion in SM13 über “Deactivate update” deaktiviert werden und bleibt manchmal nach Troubleshooting-Aktivitäten in diesem Zustand. Es gibt keine sichtbare Anzeige für Nutzer. Dialogtransaktionen bestätigen Speichervorgänge normal. Die SM13-Queue wächst leise weiter.
Enqueue Work Processes: Ein Prozess, eine Sperrtabelle
Der Enqueue Work Process verwaltet die SAP-seitige Sperrtabelle, die den konkurrierenden Zugriff auf Geschäftsobjekte im gesamten System kontrolliert. Standardmäßig gibt es einen Enqueue Work Process pro SAP-Instanz. In einer Multi-Instanz-Landschaft ohne konfigurierten Enqueue Replication Server (ERS) gibt es effektiv einen einzigen Enqueue Work Process für das gesamte System.
Enqueue-Monitoring hat zwei Dimensionen. Die erste ist die Verfügbarkeit des Enqueue Work Process: Wenn er terminiert, stoppt die Sperrverwaltung, und jede Transaktion, die eine Sperre benötigt, kann nicht fortfahren. Die zweite ist die Sperrtabelle selbst, die in SM12 überwacht wird. Eine Sperrtabelle, in der sich Einträge ansammeln, insbesondere Einträge, die von lange laufenden Programmen gehalten werden, weist auf Lock Contention hin. Nutzer, die auf dieselben Objekte zugreifen möchten wie die gesperrten Datensätze, müssen warten. In Umgebungen mit hoher Parallelität kann eine kleine Anzahl lange gehaltener Sperren eine kaskadierende Wartebedingung erzeugen, die als breite Dialog-Verlangsamung sichtbar wird.
SM12-Einträge, die in einem produktiven OLTP-System länger als einige Minuten bestehen bleiben, verdienen eine Untersuchung. Sie werden entweder von einem lange laufenden Batch Job gehalten, was korrektes Verhalten sein kann, oder von einer Nutzersitzung, die eine Transaktion gestartet, Datensätze gesperrt und dann weder abgeschlossen noch abgebrochen hat, was ein betriebliches Problem ist, das gelöst werden muss.
SM50 und SM66 richtig lesen
Die wichtigen Status und die verwirrenden
SM50 zeigt die Work-Process-Tabelle für die lokale Application-Server-Instanz. SM66 zeigt dieselbe Ansicht über alle Instanzen im System hinweg und ist damit die richtige Transaktion für jede systemweite Untersuchung. Beide zeigen dieselben Statusinformationen.
Die Statusspalte in der Work-Process-Tabelle zeigt, was jeder Prozess aktuell tut. “Waiting” bedeutet, dass der Work Process inaktiv und für neue Anfragen verfügbar ist. “Running” bedeutet, dass er aktiv ausführt. “Stopped” und “Ended” zeigen terminierte Prozesse an, die untersucht werden müssen und möglicherweise über den Work Process Manager neu gestartet werden müssen.
Der Status, der am häufigsten Verwirrung stiftet, ist “On hold” oder “PRIV”. Ein Work Process im PRIV-Modus wird von der Roll Area eines bestimmten Nutzers gehalten, was bedeutet, dass der Sitzungskontext dieses Nutzers im Speicher dieses Work Process liegt. In älteren SAP-Systemen und bei bestimmten Transaktionstypen bedeutete das, dass der Work Process exklusiv für diesen Nutzer reserviert war, bis die Sitzung endete. In modernen Systemen ist das Verhalten differenzierter, aber ein Work Process, der über längere Zeit in PRIV festhängt, stellt weiterhin eine Kapazitätsreduzierung dar.
Worauf man in SM66 während einer Untersuchung achten sollte, sind nicht nur die einzelnen Work-Process-Status, sondern das Verhältnis: Wie viele Dialog Work Processes befinden sich gleichzeitig im Status “Running”, und was führen sie aus? Ein gesundes System kann unter Spitzenlast zu einem gegebenen Zeitpunkt 60 bis 70 % seiner Dialog Work Processes im Running-Status haben. Ein System bei 95 %, bei dem mehrere Prozesse denselben Transaktionscode ausführen, ist ein System, in dem ein konkretes Programm einen Engpass verursacht.
Der lang laufende Dialogschritt: Wann untersuchen und wann handeln
Jede Zeile in SM50 und SM66 zeigt in der Spalte “Time” die verstrichene Zeit für die aktuelle Aktion. Bei Dialog Work Processes ist das die Zeit seit Beginn des aktuellen Dialogschritts. Ein Dialogschritt, der seit 45 Sekunden läuft, ist ungewöhnlich. Einer, der seit 8 Minuten läuft und nicht abgeschlossen ist, ist ein aktives Problem: Er verbraucht einen Work Process, der keine anderen Nutzer bedienen kann.
Die unmittelbar verfügbare Information in der Work-Process-Ansicht umfasst Mandant, Nutzer, Transaktionscode, Programmname und Aktionstyp, zum Beispiel sequential read, direct read oder insert. Das reicht aus, um zu erkennen, was läuft und wer es gestartet hat. Die Entscheidung, ob ein Work Process beendet werden soll, hängt davon ab, was er tut: Ein kundeneigener Report, den ein Entwickler versehentlich in Produktion gegen eine große Tabelle gestartet hat, ist ein Kandidat für sofortige Beendigung. Eine Update-Aufgabe, die eine große Warenbewegungsbuchung schreibt, sollte abgeschlossen werden dürfen.
Die Spalte “Time” in SM50 speichert keine Historie. Sie zeigt nur die aktuell verstrichene Zeit. Ein Work Process, der 12 Minuten lief und gerade abgeschlossen wurde, zeigt im nächsten Moment 0 Sekunden an. Deshalb sind SM50 und SM66 Diagnosewerkzeuge für aktive Vorfälle, keine Monitoring-Instrumente. Sie sagen, was jetzt passiert. Sie können nicht sagen, was heute Morgen um 09:15 passiert ist.
Wie eine gesättigte Instanz aussieht, bevor Nutzer anrufen
In der Praxis folgt die Sättigung von Dialog Work Processes in SM66 einem erkennbaren Muster in den 2 bis 5 Minuten, bevor Nutzer Probleme melden. Fast alle Dialog Work Processes zeigen gleichzeitig den Status “Running”. Mehrere davon zeigen verstrichene Zeiten über 10 Sekunden. Die in der Liste sichtbaren Transaktionscodes konzentrieren sich auf eine kleine Anzahl von Programmen. Der Warteschlangenzähler in der Work-Process-Übersicht beginnt zu steigen.
Die Schwierigkeit besteht darin, dass dieses Muster voraussetzt, dass jemand SM66 in Echtzeit beobachtet, was nicht nachhaltig ist. Das Monitoring-Äquivalent ist die kontinuierliche Erfassung der Dialog-WP-Belegung mit einem Alert, der ausgelöst wird, wenn die dauerhafte Belegung einen Schwellenwert überschreitet, nicht wenn sie kurzzeitig ausschlägt. Ein Anstieg auf 95 % Belegung, der 30 Sekunden während eines bestimmten Bildschirmverarbeitungsschritts dauert, ist nicht dasselbe wie 90 % Belegung über ein 10-Minuten-Fenster hinweg.
Metriken, die kontinuierlich überwacht werden sollten, nicht erst wenn etwas ausfällt
Auslastungsrate nach Work-Process-Typ und Zeitfenster
Die Kernmetrik für jeden Work-Process-Typ ist die Auslastungsrate: der Prozentsatz der Work Processes dieses Typs, die zu einem gegebenen Zeitpunkt aktiv genutzt werden, dargestellt als Trend über die Zeit und nicht als punktuelle Momentaufnahme. Eine Monitoring-Plattform sollte diese Metrik in Intervallen unter einer Minute erfassen, um kurze Sättigungsereignisse sichtbar zu machen, die sonst unbemerkt bleiben würden.
Nützliche Startwerte für Alert-Schwellen: Dialog-WP-Auslastung über 80 % für mehr als 3 Minuten löst eine Warnung aus. Über 90 % für mehr als 1 Minute löst einen kritischen Alert aus. Background-WP-Auslastung über 85 % während der Geschäftszeiten löst eine Warnung aus. Update-WP-Auslastung über 70 % für mehr als 5 Minuten löst eine Warnung aus, weil Update-Durchsatzengpässe im Gegensatz zu Dialog-Engpässen keine sofort nutzerseitig sichtbaren Symptome erzeugen, aber ein wachsendes Risiko in der Update-Queue aufbauen.
Diese Schwellenwerte sind Ausgangspunkte. Die richtigen Werte hängen von der Größe des Work Process Pools und vom normalen Lastprofil ab. Eine Instanz mit 40 Dialog Work Processes hat bei 85 % Auslastung mehr Spielraum als eine mit 10. Schwellenwerte auf das konkrete Instanzprofil zu kalibrieren, statt generische Prozentsätze anzuwenden, macht den Unterschied zwischen handlungsrelevanten Alerts und Alert-Rauschen.
Zerlegung der Antwortzeit: Wohin geht die Zeit?
Die Dialog-Antwortzeit in SAP ist die Summe mehrerer Komponenten: Wartezeit auf einen Work Process, also wie lange die Anfrage auf einen verfügbaren Work Process gewartet hat, Verarbeitungszeit, also die tatsächliche ABAP-Ausführung, Datenbankzeit, also die Ausführung von Abfragen, Roll Time, also Kontextwechsel, und Netzwerkzeit, also das Senden der Antwort an den Browser oder GUI-Client.
Die meisten Monitoring-Berichte zur Dialog-Antwortzeit zeigen die Gesamtantwortzeit. Das ist nützlich für Trendanalysen, aber nicht ausreichend, um die Ursache zu diagnostizieren, wenn Antwortzeiten steigen. Ein Anstieg durch Wartezeit auf einen Work Process erfordert eine andere Reaktion als ein Anstieg durch eine langsame Datenbankabfrage. Ersteres weist auf ein Kapazitäts- oder Planungsproblem hin. Letzteres weist auf ein Programm- oder Indexproblem hin.
Monitoring, das die Antwortzeit nach Komponenten zerlegt und auf Anomalien einzelner Komponenten statt nur auf die Gesamtsumme alertet, liefert die diagnostische Präzision, die das Betriebsteam braucht, um bei Veränderungen richtig zu handeln. Ein Anstieg der Gesamtantwortzeit von 1,2 Sekunden auf 3,4 Sekunden, bei dem die Erhöhung im Wesentlichen auf die Komponente “wait for work process” entfällt, ist eindeutig: Der Work Process Pool war zu diesem Zeitpunkt der Engpass.
Die Update-Queue: SM13 und was Ansammlung bedeutet
SM13 zeigt den Zustand der Warteschlange für Update-Anfragen. In einem gesunden System ist diese Queue kurz und leert sich schnell. Update-Anfragen werden durch Speichervorgänge von Nutzern erzeugt und innerhalb von Sekunden bis Minuten von Update Work Processes verarbeitet. Die Queue kann während einer Spitzenzeit kurz wachsen, wenn viele Nutzer gleichzeitig speichern. Sie sollte sich jedoch nicht dauerhaft aufbauen.
Drei Zustände in SM13 verdienen spezifische Monitoring-Aufmerksamkeit. Fehlgeschlagene Update-Anfragen, also Einträge mit Fehlerstatus, repräsentieren gespeicherte Transaktionen, deren Datenbank-Schreibvorgänge nicht abgeschlossen wurden. Sie erfordern eine manuelle Prüfung und entweder einen manuellen Neustart oder eine Stornierung nach Behebung der Ursache. Ein automatischer Neustart fehlgeschlagener Updates ohne Verständnis des ursprünglichen Fehlers kann das Problem verschärfen. Eine wachsende Queue-Anzahl ohne Fehlereinträge, aber mit Einträgen, die nicht altern und verschwinden, deutet darauf hin, dass der Update-WP-Durchsatz für das aktuelle Speichervolumen nicht ausreicht: Die Queue wird verarbeitet, aber nicht schnell genug. Eine statische, nicht sinkende Queue-Anzahl in Kombination mit einem deaktivierten Update-Service ist der zuvor beschriebene kritische Zustand, der sofort eskaliert werden muss.
Muster, die Sättigung vorhersagen, bevor sie entsteht
Das Lastprofil, das den Engpass verdeckt
Durchschnittsmetriken sind unzuverlässige Indikatoren für Work-Process-Sättigung. Ein System, das über den Geschäftstag hinweg 45 % durchschnittliche Dialog-WP-Auslastung meldet, klingt gesund. Dieser Durchschnitt kann jedoch aus 15 % Auslastung am Vormittag und einem wiederkehrenden Anstieg auf 95 % von 12:00 bis 12:20 bestehen, wenn ein Reporting-Job gleichzeitig mit der Nutzer-Spitzenlast zur Mittagszeit läuft.
Der Durchschnitt zeigt den Peak nicht. Der Peak ist der Moment, in dem Nutzer Probleme erleben. Monitoring, das mit 5-Minuten-Durchschnitten arbeitet, kann diesen Peak vollständig glätten. Das konkrete 20-Minuten-Fenster, in dem das System tatsächlich gesättigt ist, erscheint nur als moderater Anstieg im Tagesdurchschnitt.
Effektives Work Process Monitoring nutzt kurze Erfassungsintervalle von 30 Sekunden bis 1 Minute und speichert die rohen Zeitreihendaten, nicht nur aggregierte Durchschnitte. Ziel ist es, exakt rekonstruieren zu können, wie der Work Process Pool in jedem beliebigen 5-Minuten-Fenster der letzten 30 Tage aussah, damit von Nutzern gemeldete Langsamkeit zu einem konkreten Systemzustand korreliert werden kann, statt aus Durchschnittswerten geschätzt zu werden.
Konkurrenz zwischen Background und Dialog während Spitzenzeiten
Das vorhersehbarste Muster für Work-Process-Sättigung in vielen SAP-Umgebungen ist die Überschneidung zwischen Batch-Job-Laufzeit und Nutzer-Spitzenlast. Ein Background Job, der normalerweise um 06:00 startet und bis 08:30 endet, ist kein Problem, wenn die Nutzerlast um 08:00 beginnt. Wenn derselbe Job aufgrund des über das Jahr gewachsenen Datenvolumens nun 3 Stunden dauert, läuft er jetzt durch das Spitzenfenster von 08:00 bis 09:00, verbraucht Background Work Processes und konkurriert mit Dialognutzern um CPU.
Dieses Muster entwickelt sich meist schrittweise und wird oft erst bemerkt, wenn Nutzer morgendliche Langsamkeit melden, die sechs Monate zuvor noch nicht existierte. Das Monitoring von Job-Endzeiten gegenüber Basislaufzeiten und die Korrelation von Job-Laufzeitfenstern mit Dialog-Antwortzeittrends machen diese Überschneidung sichtbar, bevor sie stark genug wird, um Nutzerbeschwerden auszulösen.
Der konkrete Alert, der konfiguriert werden sollte: Markieren Sie jeden Background Job, der noch läuft, wenn er historisch gesehen seit mehr als 30 Minuten abgeschlossen sein sollte. Nicht weil der Job fehlschlägt, sondern weil seine verlängerte Laufzeit Ressourcenkonkurrenz in einem Zeitfenster erzeugt, das er eigentlich vermeiden sollte.
In der Praxis: Die Verteilung von Work Processes über mehrere Application-Server-Instanzen beseitigt das Sättigungsrisiko nicht, sie verteilt es nur. Eine schlecht verteilte Nutzerlast oder eine Logon-Group-Konfiguration, die die meisten Nutzer auf eine einzelne Instanz routet, kann Sättigung auf einer Instanz erzeugen, während andere unterausgelastet bleiben. SM66 zeigt die instanzübergreifende Sicht, aber die Alert-Logik muss jede Instanz einzeln bewerten, nicht nur den systemweiten Durchschnitt.
Work Process Monitoring aufbauen, das Probleme früh erkennt
Die praktische Anforderung an Work Process Monitoring ist eine kontinuierliche Datenerfassung in kurzen Intervallen, gespeichert als Zeitreihendaten statt als Momentaufnahmen. Die meisten SAP-Umgebungen verlassen sich auf SM50 und SM66 als reaktive Diagnosewerkzeuge, wofür sie gut geeignet sind. Sie ersetzen jedoch kein Monitoring, das den Zustand von Work Processes über die Zeit aufzeichnet.
Die Metriken, die pro Application-Server-Instanz, pro Work-Process-Typ, in Intervallen von 30 bis 60 Sekunden erfasst werden sollten, sind: Anzahl der Work Processes in jedem Status, also running, waiting und stopped, aktuelle Auslastungsrate, sowie bei einzelnen Work Processes mit ungewöhnlich langen Laufzeiten der Programmname und die verstrichene Zeit. Diese Daten, mindestens 30 Tage lang aufbewahrt, bilden die Grundlage, um nutzergemeldete Vorfälle mit dem tatsächlichen Systemzustand zu korrelieren.
Die Alert-Konfiguration sollte zwischen Work-Process-Typen unterscheiden, statt einen einzigen Schwellenwert auf alle anzuwenden. Dialog-WP-Auslastung braucht niedrigere Schwellenwerte und schnellere Eskalation, weil ihre Auswirkung auf Nutzer unmittelbar ist. Background-WP-Auslastung kann während geplanter Batch-Fenster höhere dauerhafte Werte tolerieren. Update-WP-Alerts sollten sich eher auf Queue-Aufbau und Fehlerzahlen konzentrieren als auf Auslastung, da Update-Fehler einen anderen Fehlermodus haben als Dialog- oder Background-Sättigung.
Die zwei Monitoring-Fähigkeiten, die über Basis-Alerting hinaus den größten diagnostischen Wert liefern, sind die Zerlegung der Antwortzeitkomponenten und die Korrelation zwischen Work-Process-Metriken und Jobplanungsdaten. Die Zerlegung der Antwortzeit identifiziert, ob eine Verlangsamung Work-Process-bezogen oder datenbankbezogen ist, ohne manuelle Untersuchung zu erfordern. Die Korrelation mit Jobplänen identifiziert Ressourcen-Konflikte zwischen Batch und Dialog, bevor sie nutzerseitig sichtbar werden.
Keine dieser Fähigkeiten erfordert eine komplexe Implementierung. Sie erfordern eine Monitoring-Plattform, die die richtigen Daten in der richtigen Granularität sammelt und sie in einer Ansicht darstellt, die das Betriebsteam nicht zwingt, während eines aktiven Vorfalls das Gesamtbild aus getrennten Transaktionsbildschirmen zu rekonstruieren.
Der feste Pool ist auch ein vorhersehbarer Pool
Work-Process-Sättigung ist einer der besser vorhersehbaren Fehlermodi im SAP-Betrieb, gerade weil die Ressource fest ist und die Nachfragemuster meist regelmäßig sind. Ein System, das jeden Montag um 09:15 gesättigt ist, wird dies am nächsten Montag wieder tun, wenn sich nichts ändert. Der Batch Job, der nun mit der Nutzer-Spitzenlast überlappt, wird dies weiterhin tun, während seine Laufzeit wächst.
Das sind keine Überraschungen. Es sind Trends, und Trends sind in Monitoring-Daten sichtbar, bevor sie zu Vorfällen werden. Das Betriebsteam, das wöchentlich die Auslastungstrends der Work Processes prüft und sie mit Batch-Planänderungen und Nutzerwachstum abgleicht, ist das Team, das eine Erhöhung der Work-Process-Anzahl oder eine Plananpassung vorschlägt, bevor Nutzer ein Problem melden, nicht danach.
Einen Work-Process-Engpass zu erkennen, bevor Nutzer ihn spüren, ist keine Frage komplexerer Tools. Es ist eine Frage der richtigen Daten in der richtigen Granularität und der Disziplin, Trends zu betrachten, statt nur den aktuellen Zustand zu prüfen, wenn jemand anruft.
Redpeaks sammelt SAP Work Process Metriken auf Instanzebene alle 30 Sekunden, mit Auslastungstrends pro Typ, Antwortzeitzerlegung und Korrelation mit Batch-Job-Aktivität. Alerts sind pro Instanz und pro Work-Process-Typ konfigurierbar. Entdecken Sie die Work Process Monitoring Coverage.
