Show TOC

ObjektdokumentationPrivater Speicher Dieses Dokument in der Navigationsstruktur finden

 

Privater (prozesslokaler) Speicher kann nicht von anderen Prozessen verwendet werden. Auch nach der Freigabe des allokierten Speichers betrachtet das Betriebssystem den (virtuellen) Speicher weiterhin als vom allokierenden Prozess belegt. Diese Merkmale des prozesslokalen Speichers erfordern, dass:

  1. der Workprozess ab der Allokierung des lokalen Speichers im PRIV-Modus (PRIVate-Modus) betrieben wird. Dies bedeutet, dass der Workprozess für die Verarbeitung des aktuellen Benutzerkontextes reserviert ist, bis der Kontext den Workprozess beim Beenden des Auftrags wieder freigibt. Bis zu diesem Zeitpunkt kann also kein anderer Benutzerkontext in den Workprozess eingeblendet werden.

  2. der Workprozess, wenn er viel privaten Speicher gebraucht hat, bei dem Abbau des Benutzerkontextes und Rückgabe des lokalen Speichers durchgestartet wird. Dieser Durchstart bewirkt, dass der lokale Speicher wieder für andere Prozesse zur Verfügung steht. Der Neustart erfolgt, wenn ein Workprozess mehr lokalen Speicher in Anspruch nimmt als im Parameter abap/heaplimit festgelegt. Dort wird der Mechanismus noch einmal genau dargestellt.

Weitere Informationen: Virtueller Adressraum eines Workprozesses

 

Wenn ein Dialog-Workprozess den ihm zugeteilten Rollbereich und Erweiterungsspeicher aufgebraucht hat, wird ihm privater Speicher zugeteilt: er geht in den PRIV-Modus.

Es ist bei der Einstellung der Parameter darauf zu achten, dass nicht zu viele Dialog-Workprozesse gleichzeitig im PRIV-Modus sind, da dies zu einer Beeinträchtigung der Performance führt.

Die anderen Workprozesstypen (Hintergrund-, Verbuchungs-, Enqueue- und Spool-Workprozesse) bekommen nach dem Rollbereich prozesslokalen Speicher zugewiesen. Die Vergabe von Erweiterungsspeicher ist nicht sinnvoll, da bei diesen Prozessen keine Kontextwechsel stattfinden.

Integration

Automatischer Abbruch von PRIV-Modus-Prozessen

Laufen zu viele der Dialog-Workprozesse in einem SAP-Applikationsserver im PRIV-Modus, entstehen Performanceprobleme. Das normale Durchführen von Benutzeranfragen wird durch die PRIV-Modus-Workprozesse verzögert.

Das SAP-System bietet einen Mechanismus an, mit dem nicht aktive Dialogprozesse, die sich im PRIV-Modus befinden, beendet werden. Mit diesem Mechanismus können Performanceprobleme verhindert werden.

Der Mechanismus funktioniert folgendermaßen:

Im PRIV-Modus können ohne irgendeine Zeitbeschränkung maximal n Dialog-Workprozesse laufen.

Sie legen n durch den Wert des Profilparameters rdisp/wppriv_max_no fest. Wenn kein Wert angegeben wird, legt das SAP-System n mit der folgenden Formel fest:

n wird auf den größeren der beiden folgenden Werte gesetzt:

  • Anzahl der Dialog-Workprozesse - 5

  • 1

Wenn mehr als n Dialog-Workprozesse aktiv sind und die Zeitspanne, die in rdisp/max_priv_time festgelegt wird (Default 600 Sekunden), verstrichen ist, wird die Transaktion desjenigen PRIV-Prozesses, der schon die längste Zeit im PRIV-Modus ist, zurückgesetzt.

Beispiel Beispiel

Sie haben 10 Dialogworkprozesse auf einer SAP-Instanz konfiguriert. Die Parameter rdisp/wppriv_max_no und rdisp/max_priv_time sind nicht verändert (Defaulteinstellung).

Dann prüft das SAP-System periodisch, ob seit über 600 Sekunden (10 Minuten) mehr als 5 Dialogworkprozesse im PRIV-Modus sind. Wenn ja, wird die Transaktion zurückgesetzt, die schon am längsten im PRIV läuft. Der Benutzer erhält ein entsprechendes Popup.

Ende des Beispiels.

Diese Parameter können im Fall von Performanceproblemen verändert werden; dies sollte aber nur in Rücksprache mit SAP geschehen.

Hinweis Hinweis

Nicht-Dialog-Workprozesse (Hintergrund, Verbuchung etc.) sind in diesem Mechanismus nicht enthalten und werden auch nicht berücksichtigt.

Ende des Hinweises