SAP-ABAP(MEMORY)

ABOUT SAP-ABAP MEMORY DETAILS:

MEMORY MANAGEMENT: BASIC CONCEPTS

·         SAP Memory Types

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).

=> 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 called the roll file. To prevent repeated copying, another roll buffer is located in between that is part of the shared memory.

Structure

The roll area consists of 2 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 the difference between the parameters ztta/roll_area and ztta/roll_first.

FOR MORE DETAILED INFORMATION, PLEASE SEE THE PLATFORM-SPECIFIC SECTION UNDER IMPLEMENTATION.

Integration

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

#                                   ROLL-IN/ROLL-OUT PROCESSING                                                     #

An ABAP/4 program only occupies a work process for one dialog step.

  1.At the beginning of the dialog step, the roll area and user context are rolled in to the work process.

 2.At the end of the dialog step, they are rolled out.

During the roll-in, pointers to the roll area and user context are populated in the work process. This enables the work process to access the data in those areas and so perform processing for that user and that program. Processing continues until the program sends a screen to the user. At that time, both areas are rolled out. Roll-out invalidates the pointers and disassociates these areas from the work process. That work process is now free to perform processing for other requests. The program is now only occupying memory, and not consuming any CPU. The user is looking at the screen that was sent, and will soon send another request.

When the next request is sent from the user to continue processing, the dispatcher allocates that request to the first available work process. It can be the same or a different work process. The user context and roll area for that program are again rolled in to the work process, and processing resumes from the point at which it was left off. Processing continues until the next screen is shown, or until the program terminates. If another screen is sent, the areas are again rolled out. When the program terminates, the roll area is freed. The user context remains allocated until the user logs off.

In a system with many users running many programs, only a few of those programs will be active in work processes at any one time. When they are not occupying a work process, they are rolled out to extended memory and only occupy RAM. This conserves CPU and enables the R/3 system to achieve high transaction throughput.

UNDERSTANDING THE TYPES OF WORK PROCESSES

There are seven types of work processes. Each handles a specific type of request. The type of work processes and the types of requests that they handle are shown in Table .

Table   Types of Work Processes and the Types of Requests they Handle

WP Type	Request Type
D (Dialog)	Dialog requests
V (Update)	Requests to update data in the database
B (Background)	Background jobs
S (Spool)	Print spool requests
E (Enqueue)	Logical lock requests
M (Message)	Routes messages between application servers within an R/3 system
G (Gateway)	Funnels messages into and out of the R/3 system

MEMORY MANAGEMENT:

PAGING AREA
Allocation of memory for the current internal session by transferring pages out of memory, similarly to operating system paging.
SAP Paging enables the roll area to be extended at ABAP runtime when a large dataset, internal tables, for example, is handled.
SAP's memory management concept currently limits SAP paging to cases where the ABAP commands EXTRACT and EXPORT... TO MEMORY... are used.

Extended Memory)(ST02-T.CODE)

#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).