25
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 Memory Management Collection by St4rcH1LD

  • Upload
    -

  • View
    480

  • Download
    2

Embed Size (px)

Citation preview

Page 1: SAP Memory Management Collection by St4rcH1LD

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.

Page 2: SAP Memory Management Collection by St4rcH1LD

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.

Page 3: SAP Memory Management Collection by St4rcH1LD

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 Default Value Unit

abap/heap_area_dia 2000000000 Byte

abap/heap_area_nondia 2000000000 (0 on 64 bit) Byte

abap/heap_area_total 2000000000 ([PM] on 64 bit) Byte

em/initial_size_MB [PM] Megabyte

em/max_size_MB 20000 (100000 on 64 bit) Megabyte

em/address_space_MB 512 (4096 on 64 bit) Megabyte

rdisp/ROLL_MAXFS [BE] * 100 8 KB block

rdisp/ROLL_SHM [BE] * 100 8KB block

rdisp/PG_MAXFS 32768 8 KB block

rdisp/PG_SHM [BE] * 50 8 KB block

ztta/roll_first 1 Byte

ztta/roll_area 2000000 (3000000 on 64 bit) Byte

ztta/roll_extension 2000000000 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.

Page 4: SAP Memory Management Collection by St4rcH1LD

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.

Page 5: SAP Memory Management Collection by St4rcH1LD

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 Number of Work Processes

1 5-7

2 10-13

4 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

Page 6: SAP Memory Management Collection by St4rcH1LD

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.

Page 7: SAP Memory Management Collection by St4rcH1LD

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 system’s 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:

Page 8: SAP Memory Management Collection by St4rcH1LD

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.

Page 9: SAP Memory Management Collection by St4rcH1LD

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.

Page 10: SAP Memory Management Collection by St4rcH1LD

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

Page 11: SAP Memory Management Collection by St4rcH1LD

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.

Page 12: SAP Memory Management Collection by St4rcH1LD

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.

Page 13: SAP Memory Management Collection by St4rcH1LD

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.

Page 14: SAP Memory Management Collection by St4rcH1LD

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 parameter’s relationship to the entire roll area (parameter ztta/roll_area).

Page 15: SAP Memory Management Collection by St4rcH1LD

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 parameter’s relationship to the initial allocation of roll memory (ztta/roll_first).

Page 16: SAP Memory Management Collection by St4rcH1LD

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.

Page 17: SAP Memory Management Collection by St4rcH1LD

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.

Page 18: SAP Memory Management Collection by St4rcH1LD

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

Page 19: SAP Memory Management Collection by St4rcH1LD

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 Max. use In memory On disk

[%] [kb] [kb] [kb] [kb]

Roll area: 5,47 448 1.280 8.192 0

Paging area 0,01 16 72 9.600 252.544

Extended Memory 4,03 6.144 22.528 152.576 0

Heap Memory 0 0 0 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)

Page 20: SAP Memory Management Collection by St4rcH1LD

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)

Page 21: SAP Memory Management Collection by St4rcH1LD

These memory classes are assigned the following values, which are also displayed in the initial screen of the rsmemory report.

Number Memory Class

0 Roll Area

1 Extended Memory (EM)

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

Page 22: SAP Memory Management Collection by St4rcH1LD

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 Value Limit:

Short-term maximum for Pages in/s (Transaction ST06) 200

Long-term maximum for Pages in/h (Transaction ST06) 600.000

Value Limit: Pages out on Windows

Pages out Value Limit:

Short-term maximum for Pages out/s (Transaction ST06) 600

Long-term maximum for Pages out/h (Transaction ST06) 1.800.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).

Page 23: SAP Memory Management Collection by St4rcH1LD

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.

Page 24: SAP Memory Management Collection by St4rcH1LD

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.

Page 25: SAP Memory Management Collection by St4rcH1LD

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