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 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.
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 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
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 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:
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 parameter’s 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 parameter’s 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 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)

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