FUNCTIONS OF THE SAP MEMORY MANAGEMENT SYSTEM

PDF download from SAP Help Portal: http://help.sap.com/saphelp_nw73ehp1/helpdata/en/49/32eff3e92e3504e10000000a421937/content.htm Created on February 09, 2014
The documentation may have changed since you downloaded the PDF. You can always find the latest information on SAP Help Portal.

Note This PDF document contains the selected topic and its subtopics (max. 150) in the selected structure. Subtopics from other structures are not included.

2014 SAP AG or an SAP affiliate company. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries. Please see www.sap.com/corporateen/legal/copyright/index.epx#trademark for additional trademark information and notices.

PUBLIC 2013 SAP AG or an SAP affiliate company. All rights reserved.

Page 1 of 10

TABLE OF CONTENT
1 Functions of the SAP Memory Management System 1.1 Memory Management Basic Terminology 1.2 SAP Memory Types 1.2.1 SAP Roll Area 1.2.2 SAP Extended Memory 1.2.3 Private Memory 1.3 User Context 1.4 Work Process 1.5 Virtual Address Space of a Work Process 1.6 Release of SAP Memory for the Operating System

PUBLIC 2013 SAP AG or an SAP affiliate company. All rights reserved.

Page 2 of 10

1 Functions of the SAP Memory Management System

Prerequisites You must be familiar with basic terminology related to memory management. You can find a summary of the terms in Memory Management: Basic Terms. Features An application runs in an SAP work process where an ABAP program is normally executed. The process requires memory to do this, which is allocated to the process by the memory management system. The order in which the work process is assigned the memory type depends on the work process type, either dialog or non-dialog (see SAP Memory Types), and the underlying operating system. The location of the various memory areas in the virtual address space is explained in Virtual Address Space of a Work Process. The user context area that allows direct access can be extended as required when the size of the user context increases. For dialog work processes, the data of the user context, including internal tables is located in this expanded area. You can therefore access all the data in the user context. Only data of types extractand export to memorystill remain in SAP Paging. The SAP Roll Areais used for the initial memory assigned to a user context, and (if available) for additional memory if the expanded memory is full. The following diagram displays the memory types that can be assigned to R/3 work processes on the SAP and operating system level. Here are the most important system profile parameters that control the availability of the memory types.

Figure 1:

Whenever a dialog step is executed, a roll actionoccurs between the roll buffer in the shared memory and the memory area, which is allocated according to ztta/roll_firstin a dialog process. Then the area in the shared memory is accessed that belongs to this user context. The following graphic displays the roll process performed by the dispatcher. Roll-in: cross-user data is rolled in from the common resource in the work process (and is processed there). Roll-out: User-specific data is rolled out from the work process in the common resource (after the dialog step has ended). The common resource stands for the different SAP memory types.

PUBLIC 2013 SAP AG or an SAP affiliate company. All rights reserved.

Page 3 of 10

Figure 2:

Using the VM Container If the SAP Virtual Machine Containeris active in your system, Java programs can also be executed. Memory management has been extended for this. For more information, see Memory Management in the VM Container More Information Work Process SAP Memory Types Virtual Address Space of a Work Process User Context

1.1 Memory Management Basic Terminology

Use The meaning of all the terms used in memory management is explained below. SAP-specific terms and features are based on this terminology. Virtual Memory All operating systems (supported by SAP) support virtual memory technology. A process allocates virtual memory using logical (virtual) addresses. Each process has its own virtual address space. (This also applies to SAP work processes, see Virtual Address Space of a Work Process.) Virtual memory is fully independent of the physical main memory. Address Space On 32 bit platforms a virtual address can have values between 0 and 2^32-1, which restricts the sizes to 4GB. As areas of the virtual address space are reserved, this leaves about 2GB available on most platforms. This is not a problem for large SAP systems. Memory Allocation Allocating memory for a process consists of the following steps:
1. 2.

Reservation of a segment in the physical memory. Linking the physical memory segment to the virtual address space of the process, which means reserving a segment of the same size in the virtual address space and mapping the virtual addresses to physical addresses.

Local Process Memory The operating system differentiates between local process memory and shared memory. For local process memory the operating system keeps the two allocation steps transparent. Using an API virtual memory only is requested; the operating system does the other tasks, such as reserving physical memory, loading and unloading virtual memory into and out of the main memory. Shared Memory If several processs are to access the same memory area, the two allocation steps are not transparent. One object is created that represents the physical memory and can be used by various processes. The processes can mapthe object fully or partially into the address space. The way this is done varies from platform to platform. Memory mapped files, unnamed mapped

PUBLIC 2013 SAP AG or an SAP affiliate company. All rights reserved.

Page 4 of 10

files, and shared memory are used. For more information see Platform-Specific Description of Memory Management.

1.2 SAP Memory Types

Definition The memory management system assigns memory to a work process. The different memory types are: SAP roll area SAP extended memory Private memory The sequence of allocation depends on the type of work process and the configuration. For more information, see Allocting Memory for User Contexts (UNIX) The user context area that allows direct access can be extended as required when the size of the user context increases. For more information, see User Context Use Roll Area The roll area is used for additional memory (if available) when the extended memory becomes full, as well as for the initial memory assigned to a user context. The limits are set using parameters. Extended Memory The large part of the user context is stored in the extended memory (EM). Page management of this memory stack is performed directly by the SAP system, and not by the operating system. This extended memory is implemented as an unnamed mapped file (on AIX and optionally on HP-UX as shared memory). This means the address space uses the paging file or uses the swap space of the operating system as background memory. For more information, please see the platform-specific documentation. When the context is changed, the user context, which is in the extended memory, is not copied as with the roll area. Instead it is allocated to alternating work processes by mapping operations. The roll area can be decreased, which results in a faster context change because less data is copied and mapping an extended area is not work-intensive. All internal tables and ABAP variables are located completely in the area of a user context that can be directly addressed. Copying and input/output operations when accessing internal tables and lists is no longer needed. The result is low CPU usage and shorter access times. Private Memory If the extended memory is fully occupied, or the limit for the work process has been exceeded, the work process allocates heap memory. This is known as private memory because it is specific to the process, and the user context can no longer be processed by a different work process (PRIV mode).

Caution
The advantages of the memory management system require increased swap space and main memory. The need for swap space increases because full-sized internal tables and lists are in the address space and take up swap space. The main memory requirements may increase to prevent excessive operating system paging due to the increased swap space requirements. For more information, see Swap Space Requirements

More Information SAP Roll Area SAP Extended Memory Private Memory

1.2.1 SAP Roll Area

Definition The roll area is a memory area with a set (configurable) size that belongs to a work process. It is located in the heap of the virtual address space of the work process. Use When the context of a work process changes, the data is copied from the roll area to a common resource known as the roll file. To prevent repeated copying, another roll bufferis located in between, which is part of the shared memory. Structure The roll area consists of two segments. The first segment, which can be set with the parameter ztta/roll_first, is assigned to the work process first as memory. If this is used up, the work process has more memory assigned to it. The amount of memory is determined by

PUBLIC 2013 SAP AG or an SAP affiliate company. All rights reserved.

Page 5 of 10

the difference between the ztta/roll_areaand ztta/roll_first parameters. For more information, see the platform-specific section under Implementation.

Note
For technical reasons, the roll area is always the first memory to receive a work process. Only afterwards can extended memory be requested.

More Information Virtual Address Space of a Work Process

1.2.2 SAP Extended Memory

Definition SAP extended memory is the core of the SAP memory management system. Each SAP work process has a part reserved in its virtual address space for extended memory. For more information, see Virtual Address Space of a Work Process You can set the size of extended memory using the profile parameter em/initial_size_MB: Extended Memory Pool Size. Configurable Under Windows, further memory is assigned dynamically as needed, and you can also set this amount. The SAP system builds a layer on to the operating system functions for the page management of this memory. This extended memory is implemented as an unnamed mapped file. This means the address space uses the paging file or uses the swap space of the operating system as background memory. Address Stability You can map the extended memory from the common resource onto any work process, and after onto another process (see graphic) on the same address in the virtual address space. This is important if you work with pointers in the ABAP program. Operating System Dependencies Depending on the operating system, how you implement the extended memory is different. Platform-Specific Description of Memory Management The section Implementation explains the implementation for the different platforms in more detail.

1.2.3 Private Memory

Definition Other processes cannot use private (heap) memory. After releasing the assigned memory, the operating system still considers the (virtual) memory as being occupied by the allocating process. These characteristics of heap memory require that:
1.

The work process can be run in PRIV mode (private) when the local memory is assigned. This means that the work process is reserved for processing the current user context until the context releases the work process again when the request has ended. Up to this time point no other user context can be mapped to the work process.

2.

The work process, if it has used a lot of private memory, is restarted when the user context is terminated and the local memory is returned. The restart makes the local memory available again for other processes. The restart occurs if a work process uses more local memory than is defined in the parameter abap/heaplimit. The mechanism is displayed again there.

For more information, see: Virtual Address Space of a Work Process Use If a dialog work process has used up the roll area assigned to it andthe extended memory, private memory is assigned to the work process. The work process goes into PRIV mode. In the parameter settings, ensure that not too many dialog work processes are simultaneously in the PRIV mode, since this lowers system performance. The other work processtypes (background, update, enqueue and spool work processes) are assigned heap memory after the roll area is used up. Allocating Extended Memory is not useful since no context change occurs for these processes. Integration Automatic Termination of PRIV Mode Processes If too many dialog work processes run in the PRIV mode in an SAP application server, performance problems arise. The normal processing of user inquiries is slowed down by the PRIV mode work processes. The SAP system offers a mechanism that lets you terminate non-active dialog processes in the PRIV mode. This mechanism helps reduce performance problems. The mechanism works as follows: In the PRIV mode, a maximum number ( n) of dialog work processes can run without any time restrictions.

PUBLIC 2013 SAP AG or an SAP affiliate company. All rights reserved.

Page 6 of 10

To determine this number n, set the value of the profile parameter rdisp/wppriv_max_no. If a value is not entered, the SAP system determines nusing the following formula: the number ( n) is set to the greater of the 2 following values: Number of dialog work processes minus 5 1 If more than ndialog work processes are active andthe time span set in parameter rdisp/max_priv_time(default 600 seconds) has elapsed, the transaction for that PRIV process, which has spent the longest possible time in PRIV mode, is reset.

Example
You have configured 10 dialog work processes on one SAP instance. The parameters rdisp/wppriv_max_noand rdisp/max_priv_timeare not changed (default settings). Then, the SAP system checks periodically if more than 5 dialog work processes are in PRIV mode after 600 seconds (10 minutes). If this is the case, the transaction is reset that has been in PRIV mode for the longest time. A corresponding dialog box appears to the user. If performance problems arise, you can change these parameters, but do this only after consulting with SAP.

Note
Non-dialog work processes (background, update, etc.) are not contained in this mechanism and are also not considered.

1.3 User Context

Definition The user context is the data that is specifically assigned to an SAP user. Use Whenever an SAP user starts a transaction (an ABAP program), the work process processing the request always requires the user context. Structure Each user can open up to six external sessions(

System Create Session ).

Note
You can configure the maximum number of external sessions with parameter rdisp/max_alt_modes, but we recommend that you do not change the default setting of six sessions. The user context contains a user-specific areacontaining user and authorization data, and a session contextfor each external session (technical term: emode). The following figure shows the structure of a user context.

PUBLIC 2013 SAP AG or an SAP affiliate company. All rights reserved.

Page 7 of 10

Figure 1: Structure of User Context

Each external session can administrate from its side multiple internal sessions (technical term imode). This is not explained in detail in this documentation. Integration All user contexts are contained in a common resource, the SAP Extended Memory, which enables a fast context change.

1.4 Work Process

Definition An SAP application server has to process SAP requests from multiple front ends. The application server has the use of a dispatcher, which gathers the requests and transfers them for processing to the work processes. The work processes then execute the desired requests (for example, an ABAP program). Use Here are the following types of work processes: Work Process Type Dialog Update Background Enqueue Spool Use Executes dialog programs (ABAP) Asynchronous database changes (is controlled by a COMMIT WORK statement in a dialog work process) Executes time-dependent or event-controlled background jobs Executes locking operations (if SAP transactions have to synchronize themselves) Print formatting (to printer, file or database)

Several dialog work processes usually run on one application server. There are usually only one or two other types of work process. Structure A work process consists of a screen processor, the ABAP interpreter, the database interface and the task handler that calls these programs. Integration The dispatcheris the central process of the application server. After it has been started, it generates the work process. You can configure the number of different types of work process that run on an application server. More Information Virtual Address Space of a Work Process

PUBLIC 2013 SAP AG or an SAP affiliate company. All rights reserved.

Page 8 of 10

Setting Up Work Process Distributionin the CCMS documentation

1.5 Virtual Address Space of a Work Process

Use With 32-bit systems, 4 GB of memory is theoretically available. Depending on the operating system, there is approximately 2 GB of virtual address space available to a process. The address space consists of a text segment, a data segment, a dynamically extendible heap, and a dynamically extendible stack. The heap increases in size from the bottom and the stack increases from the top, which enables the entire virtual address space to be used. Specific areas are reserved on the heap for an SAP Work Process. The size of these areas can be set using profile parameters. These areas are: SAP Roll Area SAP Paging Area Private Memory The largest reserved area is located between the heap and stack. This is the SAP Extended Memory. The figure below shows how SAP memory areas are mapped to operating system resources.

Figure 1: Connection Between Address Space and OS Resources

1.6 Release of SAP Memory for the Operating System

Use When memory that was allocated for SAP components in the SAP Extended Memory (EM)is released, the memory remains in the status occupied in the operating system (OS). As the SAP system sees it, the operating system handles released extended memory exactly the same as it handles memory currently occupied by SAP components. If a memory bottleneck occurs the operating system writes the memory pages to the paging file (swap space in the operating system). Before the memory pages can be used again by SAP components, the operating system has to read them back from the paging file. You can use profile parameters to set the threshold at which memory is released for the operating system. Integration The disadvantage of the process described above becomes apparent if a memory bottleneck occurs, as the operating system does not know that the content of released pages is obsolete, and has to save the content to the paging file, before the physical pages can be used for other purposes. When the pages are reused, the operating system also has to read obsolete contents from the paging file as well as provide empty memory pages. Prerequisites

PUBLIC 2013 SAP AG or an SAP affiliate company. All rights reserved.

Page 9 of 10

This function is available in a kernel patch for SAP kernel 4.6D, 6.20 and 6.40. The profile parameters are normally imported into the system from support packages (transaction RZ11). However, you can still use these parameters, even if you have not installed the relevant support package. The procedure described here does not work, if the ES/TABLE = SHM_SEGSparameter is set. In this case memory is already released for the operating system. Features You can control the amount of memory released for the operating system in relation to how busy the extended memory is, and thereby minimize the problems associated with a fully occupied extended memory. Memory above an adjustable threshold in the extended memory is always released for the operating system. As soon as this threshold is exceeded, memory below this threshold can also be released for the operating system for a specified time period. When EM blocks are released, a definable size of the upper section of the EM block can also be released for the operating system. The default procedure when memory is released is the same as the procedure described earlier, that is, no memory is released for the operating system. The release of memory for the operating system can be activated by the following parameters: es/disclaim_threshold_MB(Default: 0, inactive) specifies the threshold above which memory is released for the operating system) es/disclaim_coasting_time_alloc(Default: 0, inactive) es/disclaim_coasting_time_free(Default: 0, inactive) specifies the coasting time in seconds, how long after the threshold has been exceeded memory below the threshold is also freed up for allocation to or release from the operating system. es/blockdisclaimsize_KB(Default: 0, inactive) This parameter specifies in kilobytes the size of the upper part of an EM block that is also released for the operating system. It combines the benefit of smaller EM blocks (em/blocksize_KB) with regard to the main memory requirement, with the benefit of larger EM blocks with regard to performance. es/freelist_compactor(Default: 1) should not be 0, so that the process described above can be fully effective. Activities Import the required kernel patch. The patch text is 'CST Patch Collection 15 2004'. Set the profile parameters as you require. Example em/blocksize_KB = 4096(4MB, default for 64 bit) es/blockdisclaimsize_KB = 2048(2MB, 1/2 of em/blocksize_KB) es/disclaim_threshold_MB = 12000(OS memory release for >12GB) es/disclaim_coasting_time_alloc = 300(coasting time for OS release when allocating memory) es/disclaim_coasting_time_alloc = 60(coasting time for OS release when freeing up memory)

PUBLIC 2013 SAP AG or an SAP affiliate company. All rights reserved.

Page 10 of 10