 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
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:
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.
The common resource stands for the different R/3 memory types:
Definition
The memory management system assigns memory to a work process. There are the following memory types:
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.
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, the data is buffered in the roll buffer which is located in 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.
See:
Allocating Memory for User Contexts
Integration
For technical reasons, the roll area is always the first memory that a work process receives. Only afterwards can Extended Memory be requested.
See: Virtual Address Space of a Work Process
Definition
SAP R/3 Extended Memory is the core of the R/3 memory management system. Each R/3 work process has a part reserved in its virtual address space for Extended Memory (see Virtual Address Space in a Work Process). You can set the size using the profile parameter em/initial_size_MB. Under Windows NT, further memory is assigned dynamically as needed, and you can also set this amount.
Use
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.
Structure
Depending on the operating system, how you implement the Extended Memory is different.
Windows NT: Implementation with Map/Unmap
Here, a roll-in corresponds to mapping a context in the Extended Memory, and a roll-out corresponds to unmapping.
The following graphic displays 2 work processes that are accessing a common resource.
The common resource (memory mapped file) contains all the user contexts. The Extended Memory of a work process contains an area reserved for mapping the current user context.
The graphic displays a context change or transfer: First, the context for user X, mode Y is mapped in the Extended Memory of work process 1. The work process processes an inquiry of this context. Analogous to this, the context from user N, mode M is mapped in the reserved area of work process 2 (marked with a 1). After processing, both work processes "put" the (changed) context back in the common resource by making the context visible again.
Then work process 1 can process the context for user N, mode M and work process 2 can process the context from user X, mode Y (marked with a 2).
The start address for the mapped context is always the same.
UNIX: Implementation with Memory Protection (Protect/Unprotect)
Here, a roll-in corresponds to removing the protection for a context in the Extended Memory, and a roll-out corresponds to protecting a context.
All user contexts are always mapped in the virtual address space for each work process. At the beginning, all the contexts are protected.
The example from above changes to the following:
Work process 1 removes the protection for the context from user X, mode Y. To do this, this context is locked for all other work processes. After processing, the protection is restored. Now, work process 2 can process this context.
Integration
The R/3 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. For more information, refer to the man page "mmap" (UNIX systems), or Create File Mapping and Map View of File for Microsoft Windows NT.
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 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.
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.
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.
Integration
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:
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.
You have configured 10 dialog work processes on one R/3 instance. The parameters rdisp/wppriv_max_no and rdisp/max_priv_time are not changed (default settings).
Then, the R/3 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.
Non-dialog work processes (background, update, etc.) are not contained in this mechanism and are also not considered.
Use
The memory management system assigns memory to the user contexts from the following 3 areas: Roll area, R/3 Extended Memory and heap memory.
The order of assignment from these memory areas arranges itself according to whether the user context runs in an R/3 dialog work process or in another R/3 work process. This enables the R/3 System to optimally use the characteristics of the individual memory types.
When allocating memory, the following characteristics for individual memory types become noticeable.
Memory type | Characteristics |
R/3 roll area | Sequential memory allocation to several work processes using a relatively slow copying process |
SAP Extended Memory | Sequential memory allocation to several work processes using a fast allocation process Uses swap space |
Private memory | Allocation to a local work process, as required for the running user context in the process Uses swap space |
Flow
The flow depends on whether it is a dialog work process or not. Unlike other work process types, dialog work processes require frequent context changes. Private memory that is linked to a work process is only assigned if there are no other options.
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.
1. For technical reasons, the roll area provides the first 100 to 250 KB (depending on the operating system) that is required for the user context. Additional memory for this initial allocation is sets according to the system profile parameter ztta/roll_first. (If ztta/roll_first is set to 1 MB for example, approximately 1.2 MB roll area is provided.)
2. If the memory from the roll area is not sufficient for the user context, more memory is provided from the R/3 Extended Memory. Extended Memory remains available for the user context as long as:
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.
3. If this memory is also insufficient for the user context, more memory is provided from the roll area until this area is completely used up, or until the limit set in ztta/roll_area is reached. The roll memory now available sets itself according to the difference between the 2 parameter values ztta/roll_area (total memory in the roll area) and ztta/roll_first (size of assigned roll memory in step 1).
4. If the user context still requires additional memory, it is assigned heap memory ( Private Memory). Heap memory is available until one of the following situations occurs:
R/3 limits: Either the limit of the heap memory for dialog work processes is reached (defined in the system profile parameter abap/heap_area_dia ), or the entire heap memory of all work processes for an R/3 application server reaches its limits (defined in parameter abap/heap_area_total ).
Operating system limits for allocating memory
The swap space in the host system is used up or the upper limit of the operating system address space (as determined by the 32 bit architecture) is reached. Try to avoid these situations at all times. To avoid this situation, you must set parameter abap/heap_area_total correctly.
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.
1. The memory is taken from the roll area until the area is used up. The maximum size of the roll area is set in the system profile parameter ztta/roll_area .
2. If the roll area is full, heap memory is allocated to the work process. Heap memory is available until one of the following situations occurs:
R/3 limits: Either the limit of the heap memory for non-dialog work processes is reached (defined in the system profile parameter abap/heap_area_nondia), or the entire heap memory of all work processes for an R/3 application server reaches its limits (defined in parameter abap/heap_area_total).
Operating system limits for allocating memory
The swap space in the host system is used up. (This should never occur.)
3. If no more heap private memory can be allocated, a non-dialog work process can use the R/3 Extended Memory.
This only valid under UNIX. Under Windows NT, the memory is distributed for non-dialog processes the same as for dialog work processes. This is described more explicitly under Implementation on Windows NT.
AS/400 architecture uses a single level storage architecture (single storage principle) to implement the R/3 Extended Memory model. For this memory architecture, the main memory and the disk from the system are handled as an one address space.
Even if a large address space is assigned as an R/3 memory unit, the single level storage architecture and the dynamic memory allocation of the AS/400 operating system enable unused memory pages to be transferred, and to be available for use by other requests. Furthermore, you do not have to copy data to or from the context of the R/3 work process.
AS/400 memory pools are assigned subsystems. The resource needs of an R/3 instance are handled within a subsystem. The entire memory available for an instance is the allocated memory for the corresponding subsystem with the description R3_
Implementing R/3 Extended Memory on AS/400 has the following effects:
The implementation enables the roll area setting to be at a higher value (max. 16 MB) so that the roll extension area in the R/3 Extended Memory model is not required. The memory from the roll area is dynamically allocated up to 16 MB according to the requirements of the executed dialog steps. If you require additional memory, extended memory is allocated as planned in the R/3 memory model.
The roll area parameters ztta/roll_area and ztta/roll_first are already set to their optimal values and cannot be changed.
Since no data is copied during the swapping, the corresponding system profile parameters are not used. You must set these parameters (rdisp/ROLL_MAXFS and rdisp/ROLL_SHM) to 0 (null).
The parameter ipc/shm_psize is ignored on AS/400.
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:
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
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.
Procedure
Configuring the Memory Management System
The memory management system is preconfigured in the course of the installation/upgrade procedure. The installation/upgrade program requires information about the host system and sets the memory management parameters for each procedure either to the default values or to the values corresponding to the input. This preconfiguration is valid for the host system on which you perform the installation, and for the server you set up during the installation.
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
Note Number | Description | Operating System |
33576 | Memory management in releases as of 3.0C, UNIX and NT | UNIX, NT |
44695 | Memory management in releases as of 3.0C, AS/400 | AS/400 |
68544 | Memory Management under Windows NT | NT |
32915 | OSF1 kernel parameters for 3.0x memory management | DEC |
36410 | AIX Early versus late swap space allocation | AIX |
98153 | ABAP program buffer greater than 256 MB for AIX | AIX |
Prerequisites
Check if your host system fulfills the SAP recommendations regarding 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.
In Windows NT systems, the swap file is described as the virtual memory paging file. In the UNIX system, the term swap file or swap space is often used.
Procedure
Set the R/3 profile parameters that influence the memory management system.
Set these parameters in the instance profile that is used by the R/3 application servers in your system. For more information, see the 
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 configuration of the memory management system depends largely on the number of users for each R/3 application server. Various configurations are described in the following units:
Application Server with Up to 15 Users
Application Server with Up to 50 Users
Application Server with Over 50 Users
You can find a general parameter overview for Windows NT under Parameter Overview for Windows NT.
The values listed in the following table for the host systems and server should ensure the best possible operation of your R/3 application sever for up to 15 users. The lower limit values represent a type of minimum configuration for small R/3 installations:
Main Memory and Swap Space on the Host System
Resource | SAP Recommendation |
Size of the swap file or virtual memory paging file | Minimum: the greater of the 2 following numbers:
Recommendation: 2-3 GB |
Main memory | Minimum: 256 MB (without a database) You will achieve performance advantages with a larger main memory. Recommendation: 512 MB This value is recommended for hosts where only one R/3 server runs. If you install the database system or other servers on a host, contact the Hardware Competence Center or your system consultant. |
Work processes (Windows NT) | See Determining the Number of Work Processes |
R/3 Profile Parameters
How to use the individual parameters is described in Profile Parameters of the Memory Management.
Parameter | Recommended Value |
abap/heaplimit | 20000000 (20 mil. bytes) |
abap/heap_area_dia | 200000000 (200 mil. bytes) |
abap/heap_area_nondia |
|
abap/heap_area_total: Limit for Heap Memory | 1500000000 (1,5 GB) |
em/initial_size_MB: Size of the Extended Memory Pool | 128 (128 MB, 6 MB per user) Minimum 64 MB |
em/stat_log_size_MB: Statistics - User Context Size | 20 |
em/stat_log_timeout: Statistics - User Context Size | 600 |
rdisp/ROLL_MAXFS: Maximum Roll File Size | UNIX: 16384 Windows NT: the same value as rdisp/ROLL_SHM |
rdisp/ROLL_SHM: Roll Buffer Size | UNIX: 2048 Windows NT: 128 blocks (1 MB, per active user) |
rdisp/PG_MAXFS: Maximum Size of the R/3 Paging File | UNIX: 16384 Windows NT: the same value as rdisp/PG_SHM |
rdisp/PG_SHM: Size of the Paging Buffer | UNIX: 512 Windows NT: 13 blocks (0,1 MB, per active user) |
ztta/roll_area: Roll Area | UNIX: 6500000 (6,5 mil. bytes) Windows NT: 1000000 (1 mil. bytes) |
ztta/roll_first: Size of the Initial Allocation from the Roll Area | UNIX: 1000000 (1 mil. bytes) If more than 6 MB of extended memory is available per user (em/initial_size_MB), you can set this value to 1 (1 byte). Windows NT: 1 (1 byte) |
ztta/roll_extension: Limit for Extended Memory | 40000000 (40 mil. bytes),except for background servers under IBM AIX and Siemens-Nixdorf SINIX You can find more information in the parameter documentation |
The settings listed here are recommended base values that you may however, have to change if you monitor and optimize your R/3 System. For more detailed information , see Monitoring the Memory Management System.
Check the changes to the system profiles using the program sappfpar. For more information, see Checking the Hardware and Operating System of the Host System.
The correct configuration for the memory management system in large R/3 application servers depends on the several factors. SAP can therefore not give any recommendations for the standard configuration. However, you can calculate your own approximate values by referring to the information in this unit and in the other units that are referred to. To determine the required resources for the host system, contact the SAP Competence Center of your hardware partner Then you can configure the R/3 Server by setting the R/3 memory management parameters in the R/3 system profile.
Main Memory and Swap Space on the Host System
Resource | SAP Recommendation |
Size of the swap file or virtual memory paging file | Minimum: the greater of the 2 following numbers:
In each case, this must be larger than the sum of:
|
Main memory | Guidelines: Central system with all services, no database: 180 MB plus 5.7 MB per active user or at least 512 MB With database: Add 150 MB plus 0.3 MB per active user Application server: 120 MB plus 5.3 MB per active user More memory increases performance. Also contact your hardware partner or the SAP Competence Center for your hardware partner. |
Work processes (Windows NT) | See Determining the Number of Work Processes |
R/3 Profile Parameters
How to use the individual parameters is described in Profile Parameters of the Memory Management.
Parameter | Recommended Value |
abap/heaplimit | 20000000 (20 mil. bytes) |
abap/heap_area_dia | 2000000000 (2 GB) |
abap/heap_area_nondia | Platform dependent, see the parameter documentation |
abap/heap_area_total: Limit for Heap Memory | 2000000000 (2 GB); see the parameter documentation |
em/initial_size_MB: Size of the Extended Memory Pool | UNIX: 5 MB per active user + 1.5 MB per user; minimum 256 MB Windows NT: 8192 |
em/stat_log_size_MB: Statistics - User Context Size | 20 |
em/stat_log_timeout: Statistics - User Context Size | 600 |
rdisp/ROLL_MAXFS: Maximum Roll File Size | UNIX: 32768 (32768 8KB blocks) Windows NT: the same value as rdisp/ROLL_SHM |
rdisp/ROLL_SHM: Roll Buffer Size | UNIX: 8192 blocks or 1 MB per active user up to a maximum of 16.500 blocks (100 MB), unless more memory is required (analysis with Transaction ST02) Windows NT: 128 blocks (1 MB, per active user) |
rdisp/PG_MAXFS: Maximum Size of the R/3 Paging File | UNIX: 32768 (32768 8KB blocks) Windows NT: the same value as rdisp/PG_SHM |
rdisp/PG_SHM: Size of the Paging Buffer | UNIX: 1024 blocks Windows NT: 13 blocks (0,1 MB, per active user) |
ztta/roll_area: Roll Area | UNIX: 6500000 (6,5 mil. bytes) Windows NT: 1000000 (1 mil. bytes) |
ztta/roll_first: Size of the Initial Allocation from the Roll Area | UNIX: 1000000 (1 mil. bytes) If more than 5 MB of extended memory is available per user (em/initial_size_MB), you can set this value to 1 (1 byte). Windows NT: 1 (1 byte) |
ztta/roll_extension: Limit for Extended Memory | 128000000 (128 mil. bytes),except for background servers under IBM AIX and Siemens-Nixdorf SINIX You can find more information in the parameter documentation |
The settings listed here are recommended base values that you may however, have to change if you monitor and optimize your R/3 System. For more detailed information, see Monitoring the Memory Management System and Profile Parameters of the Memory Management.
Check the changes to the system profiles using the program sappfpar. For more information, see Checking the Hardware and Operating System of the Host System.
The correct configuration for the memory management system in large R/3 application servers depends on the several factors. SAP can therefore not give any recommendations for the standard configuration. However, you can calculate your own approximate values by referring to the information in this unit and in the other units that are referred to. To determine the required resources for the host system, contact the SAP Competence Center of your hardware partner Then you can configure the R/3 Server by setting the R/3 memory management parameters in the R/3 system profile.
Main Memory and Swap Space on the Host System
Resource | SAP Recommendation |
Size of the swap file or virtual memory paging file | Minimum: the greater of the 2 following numbers:
In each case, this must be larger than the sum of:
|
Main memory | Guidelines: Central system with all services, no database: 180 MB plus 5.7 MB per active user or at least 512 MB With database: Add 150 MB plus 0.3 MB per active user Application server: 120 MB plus 5.3 MB per active user More memory increases performance. Also contact your hardware partner or the SAP Competence Center for your hardware partner. |
Work processes (Windows NT) | See Determining the Number of Work Processes |
R/3 Profile Parameters
How to use the individual parameters is described in Profile Parameters of the Memory Management.
Parameter | Recommended Value |
abap/heaplimit | 20000000 (20 mil. bytes) |
abap/heap_area_dia | 2000000000 (2 GB) |
abap/heap_area_nondia | Platform dependent, see the parameter documentation |
abap/heap_area_total: Limit for Heap Memory | 2000000000 (2 GB); see the parameter documentation |
em/initial_size_MB: Size of the Extended Memory Pool | UNIX: 5 MB per active user + 1.5 MB per user; minimum 256 MB Windows NT: 8192 |
em/stat_log_size_MB: Statistics - User Context Size | 20 |
em/stat_log_timeout: Statistics - User Context Size | 600 |
rdisp/ROLL_MAXFS: Maximum Roll File Size | UNIX: 32768 (32768 8KB blocks) Windows NT: the same value as rdisp/ROLL_SHM |
rdisp/ROLL_SHM: Roll Buffer Size | UNIX: 8192 blocks or 1 MB per active user up to a maximum of 16.500 blocks (100 MB), unless more memory is required (analysis with Transaction ST02) Windows NT: 128 blocks (1 MB, per active user) |
rdisp/PG_MAXFS: Maximum Size of the R/3 Paging File | UNIX: 32768 (32768 8KB blocks) Windows NT: the same value as rdisp/PG_SHM |
rdisp/PG_SHM: Size of the Paging Buffer | UNIX: 1024 blocks Windows NT: 13 blocks (0,1 MB, per active user) |
ztta/roll_area: Roll Area | UNIX: 6500000 (6,5 mil. bytes) Windows NT: 1000000 (1 mil. bytes) |
ztta/roll_first: Size of the Initial Allocation from the Roll Area | UNIX: 1000000 (1 mil. bytes) If more than 5 MB of extended memory is available per user (em/initial_size_MB), you can set this value to 1 (1 byte). Windows NT: 1 (1 byte) |
ztta/roll_extension: Limit for Extended Memory | 128000000 (128 mil. bytes),except for background servers under IBM AIX and Siemens-Nixdorf SINIX You can find more information in the parameter documentation |
The settings listed here are recommended base values that you may however, have to change if you monitor and optimize your R/3 System. For more detailed information, see Monitoring the Memory Management System and Profile Parameters of the Memory Management.
Check the changes to the system profiles using the program sappfpar. For more information, see Checking the Hardware and Operating System of the Host System.
Prerequisites
Particular functions of AIX (late swap allocation, disclaim) enable an alternative implementation of the Extended Memory with a size of several GB as of R/3 Release 3.1G kernel. A single user context can still only use approximately 1 GB of Extended Memory, but the sum of usable Extended Memory for all user contexts combined can be much higher.
Since a lot of Extended Memory is provided, you can set a high limit for the shared memory consumption. It is also no longer necessary to assign mainly heap memory in background processes to keep the usage of the Extended Memory low. Heap is particularly small on AIX.
You can also minimize roll memory, which accelerates the context switch (roll-in/out) and the dialog and background processing, for example, with synchronous updating.
Procedure
Recommended parameters in the instance profile:
Parameter | Recommendation | Meaning |
ES/TABLE | SHM_SEGS | Switches to the alternative implementation of the Extended Memory (EM) |
em/max_size_MB | 4096 | Enables maximum 4 GB of Extended Memory; can be larger if needed |
ztta/roll_extension | 500000000 | Limit of approximately 500 MB (2 shared segments) of Extended Memory per user context |
ztta/roll_area | 3000000 | Reduces consumption of roll memory in background processes |
ztta/roll_first | 1 | Reduces consumption of roll memory in dialog processes |
abap/heap_area_nondia | 20000000 (20 MB) | Can be set relatively low, so that a heap bottle neck is avoided in the data segment |
The following parameters should only be changed after consulting with SAP.
Parameter | Default | Meaning |
es/shm_proc_seg_count | 3 | Specifies the number of shared memory segments that are used as shared and privately. |
es/shm_max_priv_segs | 2 | This parameter must be lower by 1 than es/shm_proc_seg_count. (=>2*256 MB is usable) |
es/shm_user_count | 1024 | This describes the maximum number of users in all open sessions. |
es/shm_user_count | This specifies the maximum number of AIX system segments that ESSHM uses. |
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 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 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
Resource | SAP Recommendation |
Free memory area ASP 1 | Minimum: 2 GB |
Main memory | 512 MB is sufficient for approx. 15 dialog users. You will achieve performance advantages with higher values. These values are valid for hosts on which only one R/3 server runs. If other servers run on the host, contact the Hardware Competence Center or your system consultant. |
Memory pool 2 | All R/3 jobs run in pool 2 according to the default values. Therefore, make as much space available for pool 2. 150-200 MB is the absolute minimum. |
R/3 Profile Parameters
Parameter | Recommended Value |
abap/heaplimit | 20000000 (20 mil. bytes) |
abap/heap_area_dia | 200000000 (200 mil. bytes) |
abap/heap_area_nondia | 2000000000 (2 GB) |
abap/heap_area_total: Limit for Heap Memory | 2000000000 (2 GB) |
em/initial_size_MB: Size of the Extended Memory Pool | 128 (128 MB, 6 MB per user) Minimum 64 MB |
em/stat_log_size_MB: Statistics - User Context Size | 20 |
em/stat_log_timeout: Statistics - User Context Size | 600 |
rdisp/ROLL_MAXFS: Maximum Roll File Size | 0 |
rdisp/ROLL_SHM: Roll Buffer Size | 0 |
rdisp/PG_MAXFS: Maximum Size of the R/3 Paging File | 16384 blocks |
rdisp/PG_SHM: Size of the Paging Buffer | 16384 blocks |
ztta/roll_area: Roll Area | 16773120 (16 MB roll area per internal mode) |
ztta/roll_first: Size of the Initial Allocation from the Roll Area | 16773120 (16 MB roll first) |
ztta/roll_extension: Limit for Extended Memory | 20000000 (20 MB extended memory per user) |
Parameter | Recommended Value (Use) |
em/stat_log_size_MB | 20 (Size above which the user context is logged for statistical purposes) |
em/stat_log_size_timeout | 600 (Interval in which statistics are gathered for the user context size) |
rdisp/PG_MAXFS | 8192 (Maximum size of the ABAP paging file - 64 MB) |
rdisp/PG_SHM | 8192 (Size of the paging buffer - 64 MB) |
The values listed here are recommended basic values. In the course of monitoring and optimizing your R/3 System, you may have to change these values under certain circumstances. For more information, refer to Monitoring the Memory Management System and Temporary Memory on AS/400.
Check the changes to the system profiles using the program sappfpar. For more information, see Checking the Hardware and Operating System of the Host System.
