Dynamische Workprozesse 
Dynamische Workprozesse ermöglichen eine Anpassung der Workprozesskonfiguration des SAP NetWeaver Application Server (AS ABAP) im laufenden Betrieb gemäß den aktuellen Anforderungen. Dies schließt das Nachstarten neuen Workprozesse und das Beenden nicht mehr benötigter Workprozesse mit ein.
Motivation
In älteren Releases gab es nur die CCMS Betriebsartumschaltung, die eine Änderung des Workprozesstyps im laufenden Betrieb ermöglicht hat. So konnten nachts Workprozesse den Typ Batch annehmen, die tagsüber vom Typ Dialog waren. Diese Typänderung erfolgte jedoch nicht dynamisch (vom System gesteuert) und ferner war es nicht möglich, im laufenden Betrieb neue Prozesse zu starten.
Die dynamischen Workprozesse ermöglichen zum einen eine Art Adaptive Computing, zum anderen kann sich das System aus Verklemmungen selbst befreien. Sie sind als Ergänzung zur Betriebsartenumschaltung zu sehen.
Adaptive Computing
Die frühere Strategie bei der Konfiguration eines Applikationsservers ging von feststehenden Hardware-Gegebenheiten aus. Die vorhandenen Hardware-Ressourcen wurden auf die laufenden Anwendungen verteilt und die Profilparameter entsprechend eingestellt. Zur Aktivierung neuer Hardware-Ressourcen war ohnehin ein Neustart des Rechners notwendig. So konnte auch die SAP-Konfiguration über die Profildatei problemlos geändert werden.
Die Idee des Adaptive Computing ist es, Anwendungen auf „virtuellen Rechnern“ laufen zu lassen, deren Ressourcen im laufenden Betrieb verändert werden können (CPUs hinzufügen usw.). Aus diesem Grund muss der Applikationsserver in die Lage versetzt werden, sich den Gegebenheiten dynamisch anzupassen:
vorhandene Hardware-Ressourcen ausnutzen
diese Ressourcen wieder freigeben, wenn sie für andere Aufgaben benötigt werden
Nach Hinzufügen weiterer CPUs zu einem virtuellen Rechner kann der Administrator diese durch Hinzufügen weiterer Workprozesse auslasten
Verklemmungen
Es kann vorkommen, dass ein Workprozess einen weiteren Workprozess benötigt, um seinen Request zu bearbeiten. Insbesondere bei Einsatz von RFC belegen Dialog-Workprozesse wieder Dialog-Workprozesse. Bei Kaskaden von RFCs, die zur Parallelisierung der Last auf einem Server eingesetzt werden, kann es so zu Deadlocks kommen. Dieses Problem ist mit herkömmlicher Konfiguration nicht zu lösen, mit dynamischen Workprozessen kann der Dispatcher Verklemmungen erkennen und Workprozesse nachstarten.
Implementierung
Das Verfahren, nach Bedarf mehr Workprozesse zur Verfügung zu haben, ist zweistufig implementiert.
Reservierte (restricted) Workprozesse
Neben den bekannten Workprozesstypen Dialog, Batch, Spool etc. gibt es den Typ reserviert. Die Anzahl von Workprozessen wird (wie bei den anderen Typen auch) zu Beginn dem Profilparameter rdisp/wp_no_restricted entnommen. Es können keine weiteren reservierten WPs im laufenden Betrieb erzeugt werden.
Reservierte Workprozesse sind immer vom Typ Dialog. Sie werden im normalen Betrieb freigehalten und erst dann verwendet, wenn das System einen Engpass feststellt und aus diesem Grund weitere WPs benötigt.
Dynamisch nachgestartete Workprozesse
Wenn die dynamischen Workprozesse aktiv sind (rdisp/dynamic_wp_check=TRUE), kann das System bis zur Grenze rdisp/wp_max_no Workprozesse nachstarten, um Verklemmungen aufzulösen. Dynamische Workprozesse können von verschiedenem Typ sein (Dialog, Batch, Verbuchung,..)
Die Möglichkeit, Prozesse dynamisch erzeugen zu können, wird auch bei der Behandlung von Deadlocks verwendet. Wenn alle Prozesse eines Typs wie z.B. Dialog im Zustand Hält sind, wird, falls möglich, ein Prozess mit diesem Typ nachgestartet. Nachdem sich der Engpass aufgelöst hat, wird der „dynamische“ Prozess dann wieder beendet (vgl. rdisp/dynamic_wp_check).
Beim Start der Instanz werden so viele Workprozesse gestartet, wie sich aus der Summe der Parameter
rdisp/wp_no_dia
rdisp/wp_no_vb
rdisp/wp_no_vb2
rdisp/wp_no_enq
rdisp/wp_no_btc
rdisp/wp_no_spo
rdisp/wp_no_restricted
ergeben. Deren Summe muss kleiner oder gleich dem Wert des Parameters rdisp/wp_max_no sein.
Bei einer Betriebsartenumschaltung kann die Anzahl der einzelnen Prozesstypen verändert werden. Es gilt aber weiterhin das Kriterium, dass die Summe den Wert von rdisp/max_wp_no nicht überschreiten kann
Standardeinstellung
In der Standardeinstellung sind keine reservierten Workprozesse konfiguriert (rdisp/no_restricted = 0), es können aber dynamisch bis zu 2 Workprozesse nachgestartet werden (rdisp/max_wp_no=<Summe aller konfigurierten WPs + 2>).
Empfehlung
Für den Fall, dass nur in Ausnahmesituationen mit Verklemmungen gerechnet wird, ist diese Einstellung passend. Falls viele RFC-lastigen Anwendungen laufen, empfiehlt es sich, mehr dynamische Workprozesse zu konfigurieren. Setzen Sie dazu den Wert auf die Summe aller konfigurierten Workprozesse plus die gewünschte Anzahl dynamischer Workprozesse (vgl. Beispiel unten).
Konfiguration
Die Konfiguration der dynamischen und reservierten Workprozesse erfolgt über Profilparameter. Alle im folgenden beschriebenen Parameter sind detailliert im System dokumentiert (Transaktion RZ11). Die neu hinzugekommenen Profilparameter sind mit einem Stern (Asterisk) markiert.
Achtung
Die maximale Anzahl von Workprozessen beträgt 600, das bedeutet, die Summe aller Workprozesstypen plus der möglichen dynamischen Workprozesse sowie der Parameter rdisp/wp_max_no ist durch diese Zahl beschränkt.
Parametername |
Bedeutung |
Einheit |
Standardwert |
|---|---|---|---|
rdisp/wp_no_dia |
Anzahl Workprozesse vom Typ Dialog |
Ganze Zahl zwischen 2 und 600 |
2 |
rdisp/wp_no_btc |
Anzahl Workprozesse vom Typ Batch (Hintergrundverarbeitung) |
Ganze Zahl zwischen 0 und 600 |
0 |
rdisp/wp_no_enq |
Anzahl Workprozesse vom Typ Enqueue (nur auf der Enqueue-Instanz >0) |
Ganze Zahl zwischen 0 und 5 |
0 |
rdisp/wp_no_vb |
Anzahl Workprozesse vom Typ V1-Verbuchung (zeitkritisch) |
Ganze Zahl zwischen 0 und 600 |
0 |
rdisp/wp_no_vb2 |
Anzahl Workprozesse vom Typ V2-Verbuchung (nicht zeitkritisch) |
Ganze Zahl zwischen 0 und 600 |
0 |
rdisp/wp_no_spo |
Anzahl Workprozesse vom Typ Spool (Drucken) |
Ganze Zahl zwischen 0 und 600 |
0 |
rdisp/wp_no_restricted* |
Anzahl reservierte Workprozesse (s.o.) |
Ganze Zahl zwischen 0 und 600 |
0 |
rdisp/wp_max_no* |
Maximale Anzahl Workprozesse inklusive dynamisch erzeugbarer Workprozesse (s.o.) |
Ganze Zahl zwischen 2 und 600 (muss größer sein als die Summe aller WP-Typen) oder DEFAULT |
DEFAULT (Summe aller WPs + 2) |
rdisp/dynamic_wp_check* |
Aktivierung der Prüfung im Dispatcher und ggfs. Starten dynamischer WPs (FALSE deaktiviert das automatische Starten von dynamischen Workprozessen durch den Dispatcher in Lastsituationen) |
Wahrheitswert |
TRUE |
rdisp/max_dynamic_wp_alive_time* |
Lebensdauer dynamischer Workprozesse: dynamische WPs sollen wieder beendet werden, wenn der Engpass beseitigt ist. Wenn sie keinen Request bearbeiten, werden sie nach dieser Zeitspanne wieder beendet. |
Sekunden |
300 |
rdisp/configurable_wp_no* |
Anzahl konfigurierbarer Workprozesse für die Betriebsartumschaltung. Um dem Dispatcher die Möglichkeit zu geben, Verklemmungen automatisch zu beheben, werden in der DEFAULT-Einstellung immer mindestens wpsForDeadlockHandling Workprozesse von der Betriebsartenumschaltung ausgenommen: configurable_wp_no = wp_max_no - wpsForDeadlockHandling wobei zurzeit der Kernel fest mit wpsForDeadlockHandling = 2 arbeitet (es ist dem Kernel vorbehalten, diese Einstellung zu ändern). Wird die Anzahl der Prozesse wie bisher durch die Anzahl der typ-spezifischen Work-Prozesse (DIA, BTC usw.) definiert, ergibt sich aus deren Summe die Anzahl der konfigurierbaren Work-Prozesse. Die maximale Anzahl der Workprozesse rdisp/wp_max_no wird entsprechend um wpsForDeadlockHandling erhöht.
Dieser Parameter sollte grundsätzlich den Standardwert DEFAULT haben. Ändern Sie den Wert nur in Ausnahmefällen und nach Rücksprache mit SAP! Ende der Warnung. |
Ganze Zahl zwischen 0 und 600 oder DEFAULT |
DEFAULT (max. Anzahl WPs minus wpsForDeadlockHandling, derzeit also Anzahl WPs minus 2) |
Übersicht
Alle derzeit laufenden Workprozesse sehen Sie in der Prozessübersicht (Transaktion SM50, vgl. Workprozesse anzeigen und steuern).
Wenn Sie 
Liste 
Konfiguration 
wählen und das Ankreuzfeld mit Info-Bereich aktivieren, sehen Sie im Kopfbereich, wie viele dynamische Workprozesse möglich sind und ob derzeit
welche laufen.
Beispiel
In dem System sind die Parameter wie folgt gesetzt:
rdisp/wp_no_dia = 16
rdisp/wp_no_btc = 3
rdisp/wp_no_vb = 1
rdisp/wp_max_no = 30
Die Prozessübersicht (Transaktion SM50) könnte dann so aussehen.
Workprozess-Übersicht
Die Angaben haben folgende Bedeutung:
Gesamtanzahl Prozesse: Anzahl der momentan laufenden Workprozesse
Dialog: Anzahl konfigurierte Dialog-Workprozesse, Anzahl derzeit freier Dialog-WPs
Verbuchung, Hintergrund,.. : analoge Information für die weiteren konfigurierten WP-Typen
Konfigurierbar: Wert des Parameters rdisp/configurable_wp_no: (hier DEFAULT, also berechnet nach der Formel max. Anzahl WPs – 2: 30–2 = 28
Dynamisch: max. Anzahl WPs – konfigurierte WPs: 30–20 = 10
Blockade-Behandlung: Hier sehen Sie, ob der Dispatcher einen zusätzlichen Workprozess zur Blockadebehandlung erzeugt hat (seit dem Start oder dem letzten Zurücksetzen. Ob der Prozess noch läuft, sehen Sie an der Gesamtzahl Prozesse. Wählen Sie
Liste Zurücksetzen , um diese Anzeige zurückzusetzen. Die Anzahl dynamischer/reservierter Prozesse wird dann auf null gesetzt, und die Zeile verschwindet aus der Anzeige.
Weitere Informationen
Informationen zur Konfiguration und Überwachung der Server-Ressourcen bei Einsatz von parallelen RFCs finden Sie in der Dokumentation Konfiguration von Systemressourcen für aRFC, tRFC, qRFC.