SAP Library - Find your answers

Symptom

Corrective action

An overview of the memory management parameters will be shown in the following sections.

A description of the parameter always follows the unit in which it is specified, the default value and a proposed value. The default value usually is based on a minimal value, therefore for very small R/3 installations (see Application Servers with Up to 15 Users), the proposed value is based on a midsize to large installation (see Application Servers with Up to 50 Users and Application Servers with Over 50 Users).

The specified default values and proposed values are based on UNIX systems; under Windows NT, the parameter setting is explained in the unit Parameter Overview for Windows NT.

abap/heaplimit: Work Process Startup

ztta/roll_extension: Extended Memory Limit

abap/heap_area_dia: Heap Memory Limit for Dialog Work Processes

abap/heap_area_nondia: Heap Memory Limit for Non-Dialog Work Processes

abap/heap_area_total: Heap Memory Limit

em/initial_size_MB: Extended Memory Pool Size

rdisp/ROLL_SHM: Roll Buffer Size

rdisp/ROLL_MAXFS: Maximum Roll File Size

rdisp/PG_SHM: Paging Buffer Size

rdisp/PG_MAXFS: Maximum Size of the R/3 Paging File

ztta/roll_area: Roll Area

ztta/roll_first: Initial Allocation Size from the Roll Area

em/blocksize_KB: Segment Size for the Extended Memory

em/stat_log_size_MB: Statistics - User Context Size

em/stat_log_timeout: Statistics - User Context Size

If with Transaction ST06 or on the CCMS Alert Monitor you notice a high paging rate in a memory pool, enlarge this pool.

• Machine Pool: This is always system pool 1.

The paging rate should be less than 10 faults per second.

• Other pools: The paging rate should be ideally less than 200 faults per second.

Using the paging mechanism lazy page out (removing the pages that are not in the address area of an active process), Windows NT creates permanently free working memory (see Special Features under Windows NT). Therefore, Transaction ST06 displays a very high value for Physical mem free in comparison to Physical mem avail (see the following graphic). Due to a faulty interpretation, the number of work processes is often increased ("There is still unused working memory available").

In the operating system OSF/1 from Digital Equipment Corporation, you must increase the value of the parameter VPAGEMAX for the Extended Memory by up to 800 MB (parameter em/initial_size_MB = 800) to 131072. You can find more information on larger memory amounts in the OSS Note 32915 in the OSS system.

VPAGEMAX defines the size of the unnamed mapped file for the R/3 Extended Memory.

The program sappfpar lets you check the minimum and maximum (worst case) swap space requirements for an R/3 application server. It also checks the shared memory requirements and if the parameters em/initial_size_MB and abap/heap_area_total are correctly set. Proceed as follows:

1. To check the instance profile for the R/3 application server, start the program sappfpar from the UNIX command line.

/usr/sap//SYS/exe/run/sappfpar check pf=/usr/sap//SYS/profile/ nr= name= | more

2. The program generates a list. Note the total value for the shared memory in the field Shared memory under Memory requirements estimated. This value corresponds to the size of the shared memory required for this profile, and must be calculated into the shared memory requirements for the new Memory Management.
3. At the end of the list, the program specifies the minimum swap space requirements, the maximum heap memory requirements and the swap space requirements in a worst case scenario:

Total, minimum requirement.....: 169.5 MB (shared memory requirement)
Process local heaps, worst case: 762.9 MB
(is set with abap/heap_area_total )
Total, worst case requirements: 962.5 MB

R/3 application servers are important users of swap space. If the swap space in a host system is used up, serious system problems occur as a result. Therefore, you must monitor swap space usage.

To monitor swap space, you can use either the monitoring tool for host operating systems or the system monitor from the SAP Computing Center Management System (CCMS). The CCMS Alert Monitor, which is available via the system monitor, issues warning messages if the swap space usage exceeds a preset limit. You can also display the present usage.

Also see:

Determining the Swap Space Currently Available

Determining the Swap Space Requirements

An R/3 application server divides its swap space with non-R/3 processes in the host system. The maximum swap space size that an R/3 application server can occupy is determined by the following factors:

• Total size of the extended memory buffer (for example, the program and table buffer)

Typical size: 200 to 500 MB

You can test this using the program sappfpar check pf= .

• Number of work processes in an R/3 server

Each work process requires approximately 12 MB of swap space plus the roll area of the active user context; therefore approximately 20 MB per work process.

• As with parameter
em/initial_size_MB, SAP Extended Memory defines (R/3 Extended Memory pool): This parameter assigns the swap space area that the R/3 System uses for its Extended Memory. The pool has a set size. The total size is allocated directly after starting the application server.

Typical values: approximately 500 MB

• R/3 limits for the local process memory (
Private Memory) for the work processes of an application server Parameter abap/heap_area_total defines these limits (maximum local private (heap) memory that can be assigned to all R/3 work processes) This is the upper limit of the swap memory that can be allocated to the R/3 work processes when they run in PRIV mode and use heap memory. The memory is allocated to the work processes in the application server taking this limit into account. The size used varies based on whether the work processes switch to or are restarted in the PRIV mode, when they leave the PRIV mode.

This parameter lets you foresee when the R/3 System requires swap space. This lets you prevent a critical shortage of swap space. Work processes cannot use heap memory resources anymore than specified in this parameter.

Typical values: 2 - 4 GB

The following prerequisites must be met so that you can use memory management with your R/3 System (Release > 4.0A):

• The swap space may not fall below a specified level.
• You may have to install additional main memory.
• You must reset various operating system parameters and, if necessary, they must be inserted in a new operating system kernel.
• You may also have to reconfigure hardware and software.

In the following sections, you will find information about the prerequisites for swap space and main memory.

For UNIX and Windows NT, refer to the following documents for more information about changes to the kernel parameters and software prerequisites:

• UNIX Systems: R/3 Installation on UNIX -- OS Dependencies. You receive this document with the installation and upgrade packages.
• Windows NT Systems: Documentation on installing and upgrading and in
Memory Management under Windows NT

The following documents contain details about hardware prerequisites for UNIX and Windows NT:

• For installations, you can find details in the installation documentation.
• For upgrades, you can find details in this document and the upgrade documentation. For additional information, see the upgrade and installation notes for the SAP online system as well.

Swap Space Requirements

Main Memory

Data Segment Size (UNIX)

Minimizing the Windows NT File Cache

VPAGEMAX under OSF/1

Shared Memory ID under IBM AIX

Memory Pool Requirements for AS/400

Checking the Hardware and Operating System of the Host System

You must ensure that Extended Memory is sufficiently large due to its intensive use. The prerequisite for this is a correspondingly large virtual memory area from Windows NT. As a basis, you need approximately 6 MB Extended Memory for each active user. Ensure that there is sufficient memory area by comparing the maximum Extended Memory used and memory created (Transaction ST02). Even during heavy system load, the value [ max use ] should not reach the value [ in memory ]. However, if this does occur, you must increase the profile parameter em/initial_size_MB accordingly.

Using the following parameters, you can limit the maximum use of the process-specific memory. This in turn limits the maximum use of temporary memory by an R/3 application server.

Consider the following parameters:

For more information about the function parameters, see Allocating Memory for User Contexts.

Temporary memory almost completely covers the memory requirements of R/3. The main consumers are:

• Internal buffers with a fixed share (PXA, table buffer, paging buffer)
• R/3 memory management (roll memory, Extended Memory, private memory) with a variable share depending on the number of users logged on and the application type (direct memory requirements)

Implementing the memory management system on AS/400 is described in Implementation on Platforms for IBM AS/400.

In the following tables, you will find information about the necessary settings for the memory management system.

• Check if your host system fulfills the SAP recommendations for main memory and swap space.

Check the resources and system-specific requirements on all host systems on which an R/3 server is to be installed. For more information, see Checking the Hardware and Operating System of the Host System.

• Set the R/3 profile parameter that uses the memory management system.

Set these parameters in the instance profile used by each R/3 application servers in your system. For more information, see the CCMS Guide.

If you modify the profiles directly with a system editor, you must perform an error check. For more information, see Checking the Hardware and Operating System of the Host System.

The values listed in the following table for the host systems and servers should ensure the best possible operation of your R/3 application sever.

Main Memory and Swap Space on the Host System

R/3 Profile Parameters

Prerequisites

Procedure

SAP Workload Analysis: Average Usage of All Memory Types (KB)

The average memory usage is calculated by dividing the total memory usage by the number of associated dialog steps.

The total memory usage is made up of the components roll memory, extended memory and heap memory. Work processes use memory in the following order:

Roll Memory to the limit set by ztta/roll_first

Extended memory to limit set by ztta/roll_extension or until there is no more space available in extended memory.

Roll Memory: rest of the space in the roll area until ztta/roll_area.

Heap Memory until abap/heap_area_dia is reached or all space in heap memory is used.

For non-dialog work processes, there used to be an allocation order.

The memory management system is automatically activated and configured using your entries during the installation or the upgrade.

Prerequisites

Before you install the R/3 System or upgrade to a 4.x version, ensure that the host system(s) on which the R/3 application server is/are set up, fulfill all the requirements particularly regarding main memory and swap space.

For more information, see:

Operating System and Hardware Prerequisites.

Also refer to the installation checklist and the installation documentation OS Dependencies.

Configuring the Memory Management System

Checking and Adjusting the Configuration

Check the preconfigured memory management system and your host system using the following sample configuration and guidelines.

Requirements for the Host:

Checking the Hardware and Operating System of the Host System

Sample Configurations:

Application Server with Up to 15 Users

Application Server with Up to 50 Users

Application Server with Over 50 Users

Configuration Help for Various Platforms:

Configuration for UNIX / Windows NT

AS/400 Configuration

Memory Management under Windows NT

Configuration for AIX

Checking the Operation of the Memory Management System and Setting Necessary Parameters if Necessary

For more information, see:

Monitoring the Memory Management System

Important OSS Notes

The basis for the Zero Administration Memory Management under Windows NT is the dynamic Extended Memory. This technique provides you with a nearly unlimited memory resource. Initially, the extended memory is set to the size of the profile parameter phys_memsize ([PM]). If the user requires more memory, Extended Memory extends itself in steps from "[PM] / 2" up to the set limits in the profile parameter em/max_size_MB , or until the address space in the NT page file is used up. By setting the default value for em/max_size_MB to 2000 MB, the size of the NT page file represents the actual limit for extending the Extended Memory. The profile parameter phys_memsize determines how much of the total main memory is used by R/3. The parameter is entered according to the input at installation. The default value for phys_memsize is the size of the main memory [MM].

The memory allocation strategy for a non-dialog work process was changed as of Release 4.0B. Through the previous allocation sequence, the extended memory was protected to the benefit of the heap memory. This is no longer necessary when using the dynamic Extended Memory, and the allocation sequence of the batch work processes is identical to the sequence of the dialog work processes (see Allocating Memory for User Contexts). Another beneficial side effect is that you can avoid the PRIV mode (see Private Memory) for background work processes and thereby the expensive restarting of work processes.

Sequence of allocating memory for non-dialog work processes:

1. Roll memory until the limit
ztta/roll_first
2. Extended memory until the limit
min {em/address_space_MB, ztta/roll_extension}
3. Roll memory until the limit
ztta/roll_area
4. Heap memory until the limit
abap/heap_area_nondia

The basis for zero administration memory management is a sufficiently large NT page file. The previous recommendation

NT page file = 3 to 4 times the main memory size

still remains.

All relevant memory management parameters are set with an optimal default value so that all manual configurations are unnecessary.

See also: Memory Management under Windows NT

Use

Flow

Allocating Memory for Dialog Work Processes

The following graphic shows how the memory management system assigns memory to a dialog work process with different memory types. Normally, dialog work processes process requests from dialog users of the R/3 System.

The work process reaches the limit of the R/3 Extended Memory for work processes. This limit is set in the system profile parameter ztta/roll_extension.

The R/3 Extended Memory is used up. The size of the extended memory pool is set in the system profile parameter em/initial_size_MB.

Allocating Memory for Other Work Processes

The following graphic shows how the memory management system assigns memory to non-dialog work process (background, update, lock and spool work processes) with different memory types.

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:

See also: Virtual Address Space of a Work Process

Use

If a dialog work process has used up the roll area assigned to it and the extended memory, private memory is assigned to the work process. The work process goes into PRIV mode (private).

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 process types (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.

Automatic Termination of PRIV Mode Processes

If too many dialog work processes run in the PRIV mode in an R/3 application server, performance problems arise. The normal processing of user inquiries is slowed down by the PRIV mode work processes.

The R/3 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.

To determine this number n, set the value of the profile parameter rdisp/wppriv_max_no . If a value is not entered, the R/3 System determines this number using 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 (n) dialog work processes are active and the 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.

If performance problems arise, you can change these parameters, but do this only after consulting with SAP.

Definition

The memory management system assigns memory to a work process. There are the following memory types:

• 
  
R/3 Roll Area
• 
  
R/3 Extended Memory
• 
  
Private Memory

To find out the order in which memory type is assigned, refer to Allocating Memory for User Contexts.

The area of a user context that is directly accessible is now extended as needed, if the user context has expanded.

Use

For dialog work processes, the data of the user context, including internal tables is located in this Extened Memory. You can therefore access all the data in the user context directly. The data types Extract and Export to Memory remain in the SAP Paging.

The roll area is used for the initial memory assigned to a user context, and (if available) for additional memory if the Extened Memory is full.

The majority of the user context is stored in the Extended Memory. Page management of this memory as a stack is not taken from the operating system; rather it is performed directly from the R/3 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, refer to the man page mmap (UNIX systems), or Create File Mapping and Map View of File for Microsoft Windows NT.

With the context change, the user context is not copied as with the roll area. Instead it is assigned 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 in/output operations when accessing internal tables and lists is no longer needed. The result is low CPU usage and shorter access times.

The advantages of the memory management system require increased swap space and main memory. The need for swap space increases because the internal tables and lists now are in the address space in their full size requiring swap space. The main memory requirements may increase to prevent excessive operating system paging due to the increased swap space requirements.

An application runs in an R/3 work process where an ABAP program is normally executed. The process requires memory to do this, which is allocated to it 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 R/3 Memory Types), and the underlying operating system.

This is described in the section Allocating Memory for User Contexts.

The location of the various memory areas in the virtual address space is explained in Virtual Address Space of a Work Process.

The area of a user context that is directly accessible is now extended as needed, if the user context has expanded. For dialog work processes, the data of the user context, including internal tables, is located in this expandable area called Extended Memory. You can therefore access all the data in the user context. The data types Extract and Export to Memory remain in the SAP Paging.

The R/3 roll area is used for the initial memory assigned to a user context, and (if available) for additional memory if the Extended Memory is full.

The advantages of the SAP memory management require increased swap space and main memory. See: Operating System and Hardware Prerequisites.

The following diagram displays the memory types that can be assigned to R/3 work processes on the R/3 and operating system level. Here are the most important system profile parameters that control the availability of the memory types.

Whenever a dialog step is executed, a roll action occurs between the roll buffer in the shared memory and the memory area, which is allocated according to ztta/roll_first in a dialog process. Then the area in the shared memory is accessed that belongs to this user context.

The following illustration displays the roll process performed by the dispatcher.

• Roll-in: User-dependent data is rolled in from the common resource in the work process (and is processed there).
• Roll-out: User-dependent 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 R/3 memory types:

This documentation introduces the SAP R/3 Memory Management System and explains which parameters are available and how you can set them to optimize your system.

This explains which hardware and operating system requirements you must fulfill and how you can monitor your memory management, discover and correct problems.

The documentation is made up of the following chapters: