Allokierung von Speicher für Benutzerkontexte (UNIX) 
Das Memory-Management-System weist den Benutzerkontexten Speicher aus den folgenden drei Bereichen zu: Rollbereich, SAP-Erweiterungsspeicher und prozesslokaler Speicher (Heap).
Die Reihenfolge der Zuweisung aus diesen unterschiedlichen Speicherbereichen richtet sich danach, ob der Benutzerkontext in einem SAP-Dialog-Workprozess oder in einem anderen SAP-Workprozess abläuft. Dadurch kann das SAP-System die Merkmale der einzelnen Speichertypen optimal nutzen.
Bei der Speicherzuweisung kommen die folgenden Merkmale der einzelnen Speichertypen zum Tragen.
Speichertyp |
Merkmale |
Sequentielle Speicherzuweisung an mehrere Workprozesse durch relativ langsamen Kopierprozess. |
|
Sequentielle Speicherzuweisung an mehrere Workprozesse durch schnellen Zuordnungsprozess. Verwendet Swap Space. |
|
Zuweisung an einen einzelnen Workprozess, wie für den im Prozess ablaufenden Benutzerkontext erforderlich. Verwendet Swap Space. |
Prozess
Der Ablauf hängt davon ab, ob es sich um einen Dialogworkprozess handelt oder nicht. Dies liegt daran, dass bei Dialogworkprozessen im Gegensatz zu anderen Workprozesstypen häufige Kontextwechsel notwendig sind. Privater Speicher, der an einen Workprozess gebunden ist, wird erst dann zugewiesen, wenn alle anderen Möglichkeiten erschöpft sind.
Speicherzuweisung für Dialog-Workprozesse
Die folgende Abbildung zeigt, wie das Memory-Management-System einem Dialogworkprozess Speicher aus unterschiedlichen Speichertypen zuweist. Dialog-Workprozesse verarbeiten in der Regel Anforderungen von Dialogbenutzern des SAP-Systems.
Aus technischen Gründen stellt der Rollbereich die erste 100 bis 250 KB (je nach Betriebssystem) Speicher für den Benutzerkontext bereit. Die zusätzliche Speichermenge dieser Initialzuweisung richtet sich nach dem Systemprofilparameter ztta/roll_first. (Wird ztta/roll_first z. B. auf 1000000 (1 MB) gesetzt, so wird etwa 1,2 MB Rollbereich zur Verfügung gestellt. Wird ztta/roll_first auf 1 gesetzt, wird nur die technisch notwendige Menge an Rollspeicher allokiert.)
Reicht der Speicher aus dem Rollbereich für den Benutzerkontext nicht aus, wird weiterer Speicher aus dem SAP-Erweiterungsspeicher bereitgestellt. Erweiterungsspeicher steht für den Benutzerkontext so lange zur Verfügung, bis eine der folgenden Bedingungen erfüllt ist:
Der Workprozess hat die Workprozess-spezifische Grenze des SAP-Erweiterungsspeichers erreicht. Diese Grenze wird im Systemprofilparameter ztta/roll_extension gesetzt.
Der SAP-Erweiterungsspeicher ist erschöpft. Die Größe des Erweiterungsspeicherpools wird im Systemprofilparameter em/initial_size_MB angegeben.
Wenn auch dieser Speicher für den Benutzerkontext noch nicht ausreicht, wird weiterer Speicher aus dem Rollbereich bereitgestellt, bis dieser Bereich vollständig erschöpft ist oder das Limit erreicht wird, das in ztta/roll_area festgelegt wurde. Der jetzt verfügbare Rollspeicher richtet sich nach der Differenz zwischen den beiden Parameterwerten ztta/roll_area (Gesamtspeicher im Rollbereich) und ztta/roll_first (Größe des in Schritt 1 zugewiesenen Rollspeichers).
Wenn der Benutzerkontext noch zusätzlichen Speicher benötigt, wird ihm prozesslokaler Speicher (Privater Speicher) zugewiesen. Prozesslokaler Speicher steht so lange zur Verfügung, bis eine der folgenden Situationen eintritt:
SAP-Beschränkungen
Entweder wird die Grenze des prozesslokalen Speichers für Dialog-Workprozesse erreicht, die im Systemprofilparameter abap/heap_area_dia definiert ist, oder der gesamte prozesslokale Speicher aller Workprozesse eines SAP-Anwendungsservers erreicht die im Parameter abap/heap_area_total angegebene Grenze.
Beschränkungen des Betriebssystems für zugewiesenen Speicher.
Swap Space im Hostsystem erschöpft oder die obere Begrenzung des Betriebssystem-Adressraums (wie durch die 32-Bit-Architektur festgelegt) erreicht.
Diese Situationen sollten unter allen Umständen vermieden werden. Um dies zu verhindern, muss der Parameter abap/heap_area_total richtig eingestellt werden.
Speicherzuweisung für andere Workprozesse
Die folgende Abbildung zeigt, wie das Memory-Management-System Nicht-Dialog-Workprozessen (also Hintergrund-, Verbuchungs-, Sperr- und Spool-Workprozessen) Speicher aus unterschiedlichen Speichertypen zuweist.
Der Speicher wird so lange dem Rollbereich entnommen, bis dieser Bereich aufgebraucht ist. Die maximale Größe des Rollbereichs wird im Systemprofilparameter ztta/roll_area angegeben.
Wenn der Rollbereich vollständig belegt ist, wird dem Workprozess prozesslokaler Speicher zugewiesen. Prozesslokaler Speicher steht so lange zur Verfügung, bis eine der folgenden Situationen eintritt:
SAP-Beschränkungen
Entweder wird die Grenze des prozesslokalen Speichers für Nicht-Dialog-Workprozesse erreicht, die im Systemprofilparameter abap/heap_area_nondia definiert ist, oder der gesamte prozesslokale Speicher aller Workprozesse eines SAP-Anwendungsservers erreicht die im Parameter abap/heap_area_total angegebene Grenze.
Beschränkungen des Betriebssystems für zugewiesenen Speicher.
Swap Space im Hostsystem erschöpft. Dies sollte nie der Fall sein, vgl. hierzu Swap Space-Bedarf
Wenn kein weiterer prozesslokaler privater Speicher zugeordnet werden kann, kann ein Nicht-Dialog-Workprozess den SAP-Erweiterungsspeicher nutzen.
Ausnahmen zu dieser Regel
Die beschriebene Allokationsreihenfolge beschreibt das Standardverhalten. Sie können für manche Plattformen ein anderes Verhalten konfigurieren:
AIX
Wenn der Parameter ES/TABLES = SHM_SEGS gesetzt ist, ist die Allokationsreihenfolge für Nicht-Dialogworkprozesse dieselbe wie für Dialog-Workprozesse (erst EM, dann Heap).
Weitere Informationen: Konfiguration für AIX
Linux
Wenn der Parameter em/implementation = map gesetzt ist, ist die Allokationsreihenfolge für Nicht-Dialogworkprozesse dieselbe wie für Dialog-Workprozesse (erst EM, dann Heap).
Weitere Informationen: Memory Management unter Linux
IBM i und Windows haben eigene Allokationsreihenfolgen. Informationen dazu finden Sie in der entsprechenden Plattform-Dokumentation.