SAP Memory Management:

User Contexts: The user context contains a user-specific area containing user and authorization data, and a session context for each external session (technical term: emode). Each external session can
administrate from its side multiple internal sessions (technical term imode). 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.

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/49/328da7e8955719e10000000a42189b/content .htm
SAP Work Process: 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). Work Process Types are Dialog, Enqueue, Update, Background & Spool. The dispatcher is 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.

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. Reservation of a segment in the physical memory. 2. Linking the physical memory segment to the virtual address space of the process, this 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 processes 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 map the object fully or partially into the address space. The way this is done varies from platform to platform. Memory mapped files, unnamed mapped files, and shared memory are used. For more information see Platform-Specific Description of Memory Management.

SAP Paging:
Memory Management (BC-CST-MM): 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.

SAP Memory Types:

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

Memory Management on Windows

The recommendations made so far for the memory management settings do not apply completely to Windows. The operating system can use other memory administration mechanisms than the various UNIX derivatives. You must evaluate the performance statistics displayed by transactions ST02 and ST06 (monitoring system performance) differently than with UNIX systems due to the above-mentioned reason.

This unit serves as a guide for setting the SAP Memory Management on Windows. By using this guide, the system administrator for a Windows application server should be better able to evaluate the performance of the system and to tune the system accordingly. Implementing the memory management system on Windows is described in Implementation on Windows. For guidelines on how to configure memory management on Windows, refer to Rules for Memory Management on Windows. For a quick overview of all important parameters, refer to Parameter Overview for Windows.

Overview of Parameters for Windows All relevant memory management parameters are set with an optimal default value so that all manual configurations are unnecessary. The following table gives you an overview of these values. Profile Parameter abap/heap_area_dia abap/heap_area_nondia abap/heap_area_total em/initial_size_MB em/max_size_MB em/address_space_MB rdisp/ROLL_MAXFS rdisp/ROLL_SHM rdisp/PG_MAXFS rdisp/PG_SHM ztta/roll_first ztta/roll_area ztta/roll_extension Default Value 2000000000 2000000000 (0 on 64 bit) 2000000000 ([PM] on 64 bit) [PM] 20000 (100000 on 64 bit) 512 (4096 on 64 bit) [BE] * 100 [BE] * 100 32768 [BE] * 50 1 2000000 (3000000 on 64 bit) 2000000000 Unit Byte Byte Byte Megabyte Megabyte Megabyte 8 KB block 8KB block 8 KB block 8 KB block Byte Byte Byte

Where: [MM] = size of the physical main memory [PM] = value of the profile parameter PHYS_MEMSIZE (default value=[MM]) [BE] = maximum possible number of users (calculated from [PM]) The zero administration memory management on Windows tries to reduce the number of relevant profile parameters so that maintenance and configuration of the application server is simplified, and the available resources are optimally used.

The basis for the Zero Administration Memory Management on Windows is the dynamic extended memory. The 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 Windows page file is used up. By setting the default value for em/max_size_MB to 20000 MB, the size of the Windows 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 the SAP system. 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 processe). Another beneficial side effect is that you can avoid the PRIV mode (see Private Memory) for background work processes and thereby starting the work processes. Sequence of allocating memory for non-dialog work processes: Roll memory until the limit ztta/roll_first Extended memory until the limit min {em/address_space_MB, ztta/roll_extension} Roll memory until the limit ztta/roll_area Heap memory until the limit abap/heap_area_nondia The basis for zero administration memory management is a sufficiently large Windows page file. The previous recommendation still remains: Windows page file = 3 to 4 times the main memory size All relevant memory management parameters are set with an optimal default value so that all manual configurations are unnecessary.

Adjusting the Windows Performance Settings

For better system performance and memory usage, you need to adjust the system settings as described below. Windows Server 2003 1. Choose Start Control Panel Network Connections Local Area Connections . 2. In the Local Area Connection Status dialog box, choose Properties. 3. In the Local Area Connection Properties dialog box, double-click File and Printer Sharing for Microsoft Networks. 4. Select Maximize data throughput for network applications. To confirm your entries, choose OK. 5. Choose Start Control Panel System . 6. In the System Properties screen, choose Advanced. 7. Under Performance, choose Settings. 8. Choose the Advanced tab.

 For Processor scheduling: Adjust for best performance of, select Background services. For Memory usage: Adjust for best performance of, select Programs. 9. Confirm your entries with OK. Windows Server 2008 1. Choose Start Control Panel System Advanced system settings . 2. In the System Properties screen, choose the Advanced tab. 3. For Performance, choose Settings.... 4. In the Performance Options window, choose the Advanced tab. 5. For Processor scheduling: Adjust for best performance of, select Background services. 6. Confirm your entries with OK.

Determining the Number of Work Processes

The context change for processes on Windows is more time-consuming compared to UNIX. Therefore, the recommended number of work processes is smaller than in UNIX systems. On Windows, the number of work processes is calculated according to the number of processors in the system and not according to the number of users. For more information see the following table. To display the work processes in the system, use transaction SM50. To determine the number of work processes, use transaction RZ04. Number of Work Processes on Windows Number of Processors 1 2 4 Number of Work Processes 5-7 10-13 20-25

Profile Parameters of Memory Management

Profile parameters enable you to set up your memory management system to get maximum benefit from it. By setting the parameters correctly, you can adjust memory management exactly to your resources and requirements. abap/heaplimit: Work Process Restart ztta/roll_extension: Limit for Extended Memory ztta/roll_extension_dia: EM Quota for Dialog Work Processes ztta/roll_extension_nondia: EM Quota for Non-Dialog Work Process abap/heap_area_dia: Heap Memory Limit for Dialog Work Processes abap/heap_area_nondia: Heap Memory Limit for Non-Dialog Work Pro abap/heap_area_total: Total Quota for Heap Memory em/initial_size_MB: Extended Memory Pool Size em/global_area_MB: Size of the Extended Global Memory rdisp/ROLL_SHM: Roll Buffer Size rdisp/ROLL_MAXFS: Maximum Roll File Size rdisp/PG_SHM: Size of the Paging Buffer rdisp/PG_MAXFS: Maximum Size of the SAP Paging File ztta/roll_first: Size of the Initial Allocation from the Roll Area

ztta/roll_area: 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 Period es/disclaim_threshold_MB es/disclaim_coasting_time_alloc es/disclaim_coasting_time_free es/blockdisclaimsize_KB es/freelist_compactor

abap/heaplimit: Work Process Restart

This value specifies the memory amount in bytes. When this amount is exceeded, a work process is restarted after executing a dialog step. Integration In a work process, heap memory (malloc) can be allocated for a user context. See Allocating Memory for User Contexts and Private Memory. If a user context releases this memory again, as the operating system sees it, the memory still remains occupied by the process, and is only available for other processes once the process itself has ended. The following chart illustrates this situation using the example of a dialog work process.

Features The value of the parameter should be between 10000000 (10 MB) and 2000000000 (2GB), the recommended default setting is 40000000 (40 MB). The objective is to have the least number of work process restarts as possible, without a swap space bottleneck occurring. The heap memory allocated by the work processes has to be released again. As shown in the graphic, the value of abap/heaplimit should be smaller than abap/heap_area_dia or abap/heap_area_nondia, so that the dialog step that is running can still be executed. This prevents the work process from working against the operating systems swap space limit if there is a programmed termination of the work process. Activities To determine how many work processes are restarted, use the Computing Center Management System (CCMS) (transaction RZ20). Note that the column Err in the Work Process Overview (transaction SM50) does not refer to work processes that are restarted.

ztta/roll_extension: Limit for Extended Memory

The value specifies the amount of memory that one user context can allocate to the SAP extended memory. This value is valid for all types of work processes. You can also control the quotas for dialog and non-dialog work processes separately. To do this use parametersztta/roll_extension_dia and ztta/roll_extension_nondia. For example, you can give a larger proportion of extended memory to batch processes than to dialog work processes. Integration The EM quotas for work processes must not be more than the total amount of extended memory. The total size of the extended memory is specified in the em/initial_size_MB parameter. Using the CCMS alert monitor (transaction RZ20), you can determine how much extended memory your servers use. The peak value displays the high water mark (maximum allocation) for extended memory. Features The parameter determines how much SAP Extended Memory a User Context can allocate. The graphic below shows this relationship:

If the value is exceeded, heap memory is allocated. The work process is assigned only to this user context and is no longer available for other user contexts, since it is switched to the PRIV mode (in the Work Process Monitor, transaction SM50). For more information, see Private Memory If the value is too high, then a large user context may cause a shortage of extended memory. If a large user context fills the SAP extended memory, it can switch other smaller work processes used for user contexts into PRIV mode before their SAP extended memory limit has been used up. Activities The default value is platform-specific and is determined dynamically. This is the default value specified in transaction RZ11. This value should not normally be changed. NOTE If you have problems with the default value, SAP recommends that you test your system with a high value (at least 500 MB). If the PRIV mode is switched on prematurely, you can decrease the size. To minimize the number of dialog work processes in the PRIV mode, keep in mind the following tips: NOTE em/initial_size_MB: should be significantly larger than ztta/roll_extension. rdisp/ROLL_SHM, rdisp/ROLL_MAXFS: If you increase the value of ztta/roll_area, you must adjust these parameters.

ztta/roll_extension_dia: EM Quota for Dialog Work

Processes This parameter specifies the maximum SAP Extended Memory that can be used for dialog work processes. Integration Previously, both non-dialog processes (BTC, UPD, UP2, SPO, etc.) and dialog processes were handled the same regarding the allocation of extended memory. You could not allocate separate EM quotas for dialog users and batch users. The quota was determined by ztta/roll_extension and was valid for all work process types. Only the heap memory had a separate quota (compare abap/heap_area_dia and abap/heap_area_nondia). To ensure compatibility with the earlier implementation, the following rules apply: If ztta/roll_extension_dia or ztta/roll_extension_nondia are not set (DEFAULT.PFL or instance profile), the value in ztta/roll_extension (old procedure) applies for ALL work process types. If, on the other hand, ztta/roll_extension_(non)dia is set, the value inztta/roll_extension is overwritten for the work process type in question. Activities The value is specified in bytes. The minimum is 20000000 (20 MB); the maximum is 64000000000 (64GB, for 64 bit platforms). The default setting is the value of ztta/roll_extension.

ztta/roll_extension_nondia: EM Quota for Non-Dialog Work Processes

This parameter specifies the maximum SAP Extended Memory that can be used for non-dialog work processes. Integration Previously, both non-dialog processes (BTC, UPD, UP2, SPO, etc.) and dialog processes were handled the same regarding the allocation of extended memory. You could not allocate separate EM quotas for dialog users and batch users. The quota was determined by ztta/roll_extension and was valid for all work process types. Only the heap memory had a separate quota (compare abap/heap_area_dia and abap/heap_area_nondia). To ensure compatibility with the earlier implementation, the following rules apply: If ztta/roll_extension_dia or ztta/roll_extension_nondia are not set (DEFAULT.PFL or instance profile), the value in ztta/roll_extension (old procedure) applies for ALL work process types. If, on the other hand, ztta/roll_extension_(non)dia is set, the value in ztta/roll_extension is overwritten for the work process type in question. Activities The value is specified in bytes. The minimum is 20000000 (20 MB); the maximum is 64000000000 (64GB, for 64 bit platforms). The default setting is the value of ztta/roll_extension. RECOMMENDATION This allows you to allocate more extended memory for memory-intensive batch work processes than for dialog work processes.

abap/heap_area_dia: Heap Memory Limit for Dialog Work Processes

This quota restricts the amount of heap memory (Private Memory) that an SAP dialog work process can allocate. This ensures that there is enough swap space available. NOTE Local memory is hardly needed any more with modern 64 bit platforms, as the memory requirement can be satisfied by the SAP Extended Memory. Integration The graphic below shows the relationship with abap/heaplimit.

If the value of abap/heaplimit has been reached, the work process is restarted after the dialog step has ended. If the consumption of heap memory exceeds the quota abap/heaparea_(non)dia, the user context being executed at this time is cancelled before it can be completed. You can use this quota to prevent one single dialog work process (user context) from filling the entire heap memory of the application server. The work processes of an application server can allocate only so much heap memory as specified in parameterabap/heap_area_total. The limit specified in the parameter refers to the combined heap memory usage of all work processes for an application server. Activities The value is specified in bytes. The default value is platform-specific and is determined dynamically. This is the Defaultwert specified in transaction RZ11. This value should not normally be changed. NOTE Ensure that the value is high enough to fulfill all the regualr memory requirements, but is not so high that the work process runs up against the swap space limit of the operating system. See the graphic in abap/heaplimit: Work Process Restart..

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

This parameter restricts the amount of heap memory (Private Memory) that an SAP non-dialog work process can allocate. This value refers to spool, update, and background processes. This value ensures that enough swap space is available in the system. NOTE Local memory is hardly needed any more with modern 64 bit platforms, as the memory requirement can be satisfied by the SAP Extended Memory. Integration The graphic below shows the relationship with abap/heaplimit.

If the value of abap/heaplimit has been reached, the work process is restarted after the dialog step has ended. If the consumption of heap memory exceeds the quota abap/heaparea_(non)dia, the user context being executed at this time is cancelled before it can be completed. You can use this quota to prevent one single non-dialog work process (user context) from filling the entire heap memory of the application server. The work processes of an application server can allocate only so much heap memory as specified in parameterabap/heap_area_total. The limit specified in the parameter refers to the combined heap memory usage of all work processes for an application server. Activities The value is specified in bytes. The default value is platform-specific and is determined dynamically. This is the default value specified in transaction RZ11. This value should not normally be changed. NOTE The value should be high enough for the largest possible background processing context in your SAP system. If the value is too small, SAP Extended Memory is assigned to the background process. This extended memory is not available for dialog work processes. See Allocating Memory for User Contexts.

abap/heap_area_total: Total Quota for Heap Memory

This parameter determines the upper limit of heap memory in bytes available to all work processes of an SAP application server. You can use this upper limit to restrict the swap space usage of an SAP application server to a specific amount. You can find more details on this topic under Functionality of the SAP Memory Management System. Integration The graphic below shows the relationship with the parameters abap/heap_area_dia, abap/heap_area_nondia, andztta/roll_extension.

Activities The value is specified in bytes. The default value is platform-specific and is determined dynamically. This is the default value specified in transaction RZ11. This value should not normally be changed. NOTE This value ensures that even at maximum swap space usage of the SAP system and during normal operation, at least 100 MB swap space (or approximately 10-15%) remains free. See also Swap Space Requirements.

em/initial_size_MB: Extended Memory Pool Size

This value specifies the extended memory pool size that the SAP system manages for the SAP Extended Memory. The value is stated in megabytes. Integration Ideally, this pool is large enough to contain the sum of all the user contexts. The pool must always be larger than the size of the parameter ztta/roll_extension. This parameter specifies how much extended memory can be allocated from the pool to one user context. If the pool is used up, heap memory is allocated (see Private Memory and Allocating Memory for User Contexts). The work process switches to the PRIV mode and is reserved exclusively for the current user context. After processing the user context, the work process might restart automatically if the process size specified in abap/heaplimit is exceeded. Activities The default value is platform-specific and is determined dynamically. This is the default value specified in transaction RZ11. This value should not normally be changed. The value must be between 32 and 8096. Keep in mind the following notes about the pool size: RECOMMENDATION Ensure that the pool is 10 to 15 times as big as ztta/roll_extension. The exact value depends on the available swap space and the number of users in the host system. NOTE The swap space must be sized so that it can contain the SAP extended memory and has enough space for the SAP usage of heap memory (see Swap Space Requirements). There must also be enough space available for competing system users outside of the SAP system. The swap space must also be large enough to ensure a safety reserve.

em/global_area_MB: Size of the Extended Global Memory

This value specifies (in megabytes) the maximum size of that part of extended memory (see also parameter em/initial_size_MB) that is reserved for global data, that is, user-independent and work process-independent data. The amount of data involved is comparatively small (a percentage of the whole extended memory pool), because only administration data belonging to internal communication between SAP kernel components (task handler, enqueue) is stored in the global area. Activities The default value is platform-specific and is determined dynamically. This is the default value specified in transaction RZ11. This value should not normally be changed. RECOMMENDATION The parameter should be approximately 5 10% of the parameter em/initial_size_MB.

rdisp/ROLL_SHM: Roll Buffer Size

This value specifies the size of the roll buffer in 8 KB blocks. The roll buffer functions as the cache for the roll file. For a fast change of context to occur, the roll areas of all user contexts should find space in the roll buffer (approximately 1 MB for each user). Buffered data is in the shared memory; accessing this data here is much faster than accessing a file.

Activities The default value is platform-specific and is determined dynamically. This is the Defaultwert specified in transaction RZ11. This value should not normally be changed. CAUTION For technical reasons, the roll buffer size must be at least 10% of the roll file size (parameter rdisp/ROLL_MAXFS: Maximum roll file size).

rdisp/ROLL_MAXFS: Maximum Roll File Size

This value specifies the size of the roll file in 8 KB blocks. The roll file functions as memory for the portion of the user contexts that finds space in the Roll Area. Integration The roll buffer is used to buffer accesses to the roll file. The buffer size is determined by the rdisp/ROLL_SHM parameter. Activities The default value is platform-specific and is determined dynamically. This is the Defaultwert specified in transaction RZ11. This value should not normally be changed. Problems should not occur even if the buffer size is large. NOTE Space must be available in the file system.

rdisp/PG_SHM: Size of the Paging Buffer

This value specifies the size of the paging buffer in 8 KB blocks. The default value is platform-specific and is determined dynamically. This is the default value specified in transaction RZ11. This value should not normally be changed. Refer also to: SAP Paging.

rdisp/PG_MAXFS: Maximum Size of the SAP Paging File

This value specifies the size of the SAP paging file in 8 KB blocks. The paging file functions as memory for extracts and exports to memory. Refer also to: SAP Paging. Activities The default value is platform-specific and is determined dynamically. This is the default value specified in transaction RZ11. This value should not normally be changed. NOTE Problems should not occur even if the size of the paging file is large. You just need to ensure there is enough space in the file system.

ztta/roll_first: Size of the Initial Allocation from the Roll Area

This parameter determines the amount of roll memory in bytes that is allocated to a dialog work process, before SAP Extended Memory is allocated. The graphic below shows the parameters relationship to the entire roll area (parameter ztta/roll_area).

Integration You can find more information under: Allocating Memory for User Contexts (UNIX) SAP Roll Area Activities The default value is platform-specific and is determined dynamically. This is the default value specified in transaction RZ11. This value should not normally be changed. On 64 bit platforms, where there is sufficient extended memory, the default value of this parameter is 1, the work process therefore is allocated extended memory straight away.

ztta/roll_area: Roll Area

This parameter is used to specify the total size of the roll area, in bytes. The following graphic shows the parameters relationship to the initial allocation of roll memory (ztta/roll_first).

A part of this area (in the graphic, roll area 1) is allocated a user context at the beginning. Its size is defined in ztta/roll_first. The partial area is for the data that must be contained in the roll area. When a user context is changed, this data is rolled (copied) into and out of a work process. If ztta/roll_area is larger than ztta/roll_first, the additional space makes a second part available (Roll area 2). If the user context cannot be allocated more extended memory, this second part of the roll area is available for the dialog processes (see Allocating Memory for User Contexts). Integration By specifying a higher value for ztta/roll_area than for ztta/roll_first, you avoid allocating local private memory as soon as the set limits of the SAP extended memory are reached. The remaining roll memory therefore serves as the last buffer before a user context has to allocate heap memory. This pushes back the point in time at which a work process is switched to PRIV mode (see Private Memory). Although there are advantages with this procedure, there are also some disadvantages: The copying procedure is much slower for storing data in the roll area for changing work process contexts. The copy procedure necessary for the roll area with context changes is slower than the allocation procedure used for context changes with SAP extended memory. Therefore, increasing the roll area memory slows down the context change. Activities The roll area is not important with 64 bit platforms where sufficient extended memory is available. The default value is platform-specific and is determined dynamically. This is the default value specified in transaction RZ11. This value should not normally be changed. If you still have to make changes on your platform, keep in mind the following dependencies: CAUTION rdisp/ROLL_SHM should be adjusted if you change ztta/roll_area. rdisp/ROLL_MAXFS should be adjusted if you change ztta/roll_area.

ztta/roll_area must be larger than or the same size as ztta/roll_first.

em/blocksize_KB: Segment Size for the Extended Memory

This value specifies the size in kilobytes of the segments that are assigned to the SAP Extended Memory. If a user context requests extended memory, a segment of this size is allocated from the extended memory pool. The default value is platform-specific and is determined dynamically. This is the default value specified in transaction RZ11. This value should not normally be changed. CAUTION Only SAP is allowed to change this parameter.

em/stat_log_size_MB: Statistics - User Context Size

In the SAP memory management system, if the sizes of user contexts exceed the specified value, they are collected for statistical purposes. The data is then written at regular intervals to a file. The interval frequency is determined by the parameter em/stat_log_timeout. The default value of 20MB should not normally be changed.

em/stat_log_timeout: Statistics Period

In the SAP memory management system, the sizes of user contexts are collected for statistical purposes. This parameter specifies the time interval at which the sizes are logged . The value specified is minutes. So a value of 5 means that the sizes are logged every five minutes. The default setting is 0, which means logging is inactive.

es/disclaim_threshold_MB
This parameter is used to control the release of SAP Extended Memory for the operating system. For more information see Release of SAP Memory for the Operating System. Features This parameter determines the threshold value in MB. If memory blocks are requested above this threshold, for instance when there is a high load, these blocks are released for the operating system at the same time as they are released for the SAP system. A value of 0 means that this parameter is inactive. This is also the default setting. More Information es/blockdisclaimsize_KB es/disclaim_coasting_time_alloc es/disclaim_coasting_time_free

es/disclaim_coasting_time_alloc
This parameter is used to control the release of SAP Extended Memory for the operating system. For more information see Release of SAP Memory for the Operating System.

Features The parameter specifies in seconds how long after the threshold specified in es/disclaim_threshold_MB has been exceeded when a block held in the swap space was allocated, that this block is to be released for the OS. A value of 0 means that this parameter is inactive. This is also the default setting. NOTE Free blocks held in the swap space should be first read from the hard disk. But as the content is obsolete it is better for system performance to release this block for the OS and to request a new block from the main memory.

es/disclaim_coasting_time_free
This parameter is used to control the release of SAP Extended Memory for the operating system. For more information see Release of SAP Memory for the Operating System. Features Similar to the es/disclaim_coasting_time_alloc parameter, this parameter determines how long after the threshold specified byes/disclaim_threshold_MB has been exceeded when releasing a block, that this block is to be released for the operating system. The value is specified in seconds. A value of 0 means that this parameter is inactive. This is also the default setting. RECOMMENDATION With high system loads a block released for the SAP system is probably written to the swap space, that is, to the hard drive. But as the content is obsolete, system performance is better to release this block for the operating system.

es/blockdisclaimsize_KB
This parameter is used to control the release of SAP Extended Memory for the operating system. For more information see Release of SAP Memory for the Operating System. Features 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. The size of EM blocks is determined by the em/blocksize_KB parameter. A value of 0 means that this parameter is inactive. This is also the default setting. More Information es/disclaim_threshold_MB es/disclaim_coasting_time_alloc es/disclaim_coasting_time_free

es/freelist_compactor
You can use this parameter to make better use of the EM blocks when activating and deactivating loads. You can reduce fragmentation in the extended memory by using this parameter. The procedure is active in the default setting and SAP recommends that you do not change this value (1).

Checking Roll /Paging Area and Extended Memory in ST02

On the initial screen of transaction ST02 (Tune Summary) you can see the following overview of the SAP Memory under the Buffer overview. SAP memory Current use [%] Roll area: Paging area Extended Memory Heap Memory 5,47 0,01 4,03 0 [kb] 448 16 6.144 0 Max. use [kb] 1.280 72 22.528 0 In memory [kb] 8.192 9.600 152.576 0 On disk [kb] 0 252.544 0 0

This is a snapshot of the current (percentage and absolute values in kilobytes) and the maximum memory usage of the various SAP Memory Types. The table also indicates whether, and to what extent, the requirement is satisfied from the main memory and from the disk. Procedure You can determine from the Extended Memory row that the SAP Extended Memory is sufficiently large. The value [Max. use] is, in this example, noticeably smaller than the created memory area [In memory]. If both values are identical, you must increase the extended memory (profile parameter: em/initial_size_MB).

Monitoring Memory Resources Using Transaction ST06

The initial screen of the OS monitor (transaction ST06) shows the configured swap space. For more information, see Swap Space Requirements Procedure If you choose Detail Analysis Menu on the initial screen of transaction ST06, you can display the memory requirements and the swap space, either as a snapshot or from over a period of hours. (the pushbuttons Memory and Swap).

(ST06 Initial Screen)

Swap Space Requirements

SAP application servers are important users of swap space. If the swap space on a computer is used up, serious system problems occur as a result. RECOMMENDATION For optimal performance SAP recommends the following swap space: 20 GB on 64 bit systems 3-6 GB on 32 bit Linux Why? 64-bit technology means that the address space can now be used more generously. This minimizes maintenance requirements and the problems associated with memory management, since the size of the buffers and other areas in the shared memory can be increased considerably so that programs do not reach the system limits. As a result, there is no risk of program crashes due to memory bottlenecks and no need for complex parameter tuning. NOTE Large parameter values and address spaces do not automatically mean more main memory is required. The main memory required is determined by the extent to which the configured areas are actually used. Expanding the swap space may require additional disk space in certain circumstances. This is highly recommended due to inexpensive hardware prices. The additional swap space requirements may be higher for application servers where heavy online operations and background jobs with large data volumes alternate (day/night operation). Independent of the swap space size, you should monitor the swap space itself to avoid bottlenecks. Monitoring 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.

The rsmemory Report

You can use the rsmemory report to define your memory allocation strategy for work processes. You can specify the memory class assigned to a work process, the extent of the class assigned, and the order in which it is allocated. A distinction is made here between dialog work processes and non-dialog work processes (batch, update, spool). NOTE Changes made here only apply to the server on which you are currently logged on, and only remain in effect until the SAP instance is stopped again. Prerequisites You are familiar with the SAP Memory Management concept and have read section Functions of the SAP Memory Management System. Features The SAP system has the following memory classes: SAP Roll Area SAP Extended Memory Private Memory (Heap Memory)

These memory classes are assigned the following values, which are also displayed in the initial screen of the rsmemory report. Number 0 1 2 Memory Class Roll Area Extended Memory (EM) Private memory (heap)

The initial screen of the report is structured as follows:

The screen comprises three parts: Quota Dialog The allocation strategy for dialog work processes is defined here. You can specify the steps in which each class is allocated memory, and how much memory is allocated. CAUTION No entry in the memory class field corresponds to class 0 (roll memory). The entry here does not have to match the defined memory parameters. If you enter a value for the heap memory in the 4th step that is different from the abap/heaparea_dia parameter, the value entered here takes precedence. NOTE In this case, 1 byte of roll area is first allocated by a dialog work process (due to technical reasons), and then a maximum of 2 GB of extended memory is available. This does not mean that the work process is assigned too much memory, since the resource is shared by all work processes. If the work process is not assigned any more extended memory, it can allocate another 6.5 MB of roll memory. Then it goes into PRIV mode and allocates heap memory (maximum 2 GB). Quota Batch/VB/Spool As with Quota Dialog the allocation strategy here is specified for non-dialog work processes. More information: Allocting Memory for User Contexts (UNIX)

Other parameters You can change the following memory parameters here for test purposes (these changes only apply until the next server restart): abap/heap_area_dia abap/heap_area_nondia abap/heap_area_total em/stat_log_timeout em/stat_log_size_MB

Displaying the Memory Areas You can display a list of all the users on the application server, with their respective memory requirements, by choosing Goto EM/HEAP Areas . The used heap memory and extended memory of the user are displayed first, followed by the EM usage according to internal sessions. This is followed by a history of users who have used more than the MB limit specified by em/stat_log_size_MB. The available HEAP and EM memory is displayed at the end of the list. EG Overview The two pushbuttons EG Overview and EG Dump are used for analysing the extended global memory. This is part of the extended memory available for internal SAP requests. Its size is specified in the em/global_area_MB parameter. Activities On the initial screen of transaction SE38, enter report rsmemory and choose (Execute) or F8.

Windows: Checking Page Fault Rates

In transaction ST06 make sure that your system does not exceed the following values for Pages in/Pages out: Value Limit: Pages in on Windows Pages in Short-term maximum for Pages in/s (Transaction ST06) Long-term maximum for Pages in/h (Transaction ST06) Value Limit: Pages out on Windows Pages out Short-term maximum for Pages out/s (Transaction ST06) Long-term maximum for Pages out/h (Transaction ST06) Value Limit: 600 1.800.000 Value Limit: 200 600.000

NOTE If you use Windows Server 2003, apply SAP Note 1009297 (Microsoft patch for Windows to improve the page-out algorithm for SAP systems).

Windows: Checking Unused Physical Memory Using ST06

Procedure Using the paging mechanism lazy page out which removes the pages that are not in the working set of an active process, Windows creates permanently free physical memory. For more information, see Special Features on Windows. Therefore, transaction ST06 is of very high value for Physical mem free in comparison to Physical mem avail. Therefore make sure that you have enough unused physical memory available before you increase the number of work processes. NOTE A high Physical mem free value has no bearing on system utilization. Physical mem free in relation to Physical mem avail is by definition very large.

Swap Space Bottleneck During SAP Operation

Procedure Symptom Various error messages that indicate a storage bottleneck (more correctly: a swap space shortfall) such as: System Panic;cmemreserve: reservation overrun; ENOMEM, Not enough core; ENOSPC, No space left on device; SIGDANGER(only under AIX). In the SAP system the SAP system log message "no memory of class perm" is output. This problem can occur with both SAP processes and external processes. The relevant process cannot allocate any more heap memory. This can lead to the database operation being ended or SAP work processes being stopped. In the SAP system, error messages appear in the developer trace files dev_disp, dev_w<n>, in the system log and in dumps. The following messages may appear: TSV_TNEW_;._NO_ROLL_MEMORY; NO_MEM; NO_MEMORY; RESIZE_EM_ALLOC_ERROR, Storag e class PERM. This problem mostly occurs if background jobs are active with large amounts of data. Possible Causes There is no more swap space available (Swap Space Requirements). The highest value for one of the SAP profile parameters that limit the swap space usage has been exceeded. In this case, the following parameters are relevant: abap/heap_area_dia, abap/heap_area_nondia and abap/heap_area_total. Corrective Action Increase the swap space as described in Swap Space Requirements.

Slow Response Times for Some Users, Very Good Response Times for Other Users
Prerequisites The SAP extended memory is completely filled; dialog work processes are switched to PRIV mode. Procedure Use transaction SM50 to determine the work processes in the PRIV mode.

Possible causes /Corrective action No more SAP Extended Memory is available.

In this example, work processes 5 and 6 cannot allocate any more extended memory because the pool is used up, although its limit for ztta/roll_extension would still allow extended memory. They switch into PRIV mode prematurely (see Allocating Memory for User Contexts) Action: Increase the SAP extended memory pool (em/initial_size_MB: Size of Extended Memory Pool), to prevent work processes from being switched to the PRIV mode. The limit for the extended memory is too low for most user contexts (set with parameter ztta/roll_extension). Many contexts allocate heap memory and switch to PRIV Mode.

Action: Increase the limit for the extended memory using ztta/roll_extension.

The limit for the extended memory is too high. A few user contexts can completely fill the entire extended memory, whereby other processes are switched into PRIV mode before the limit is reached.

Reduce the limit on the extended memory (defined in ztta/roll_extension), or increase the extended memory (seeem/initial_size_MB). COLLECTED FROM:

http://help.sap.com/saphelp_nw70ehp1/helpdata/en/49/325d4ee93934ffe10000000a421937/fram eset.htm