SAP Paging

Definition
SAP paging is the allocation of memory for the current internal session by moving memory pages, similar to
the operating system paging.

Use
SAP paging enables you to extend the roll area at ABAP runtime if a large amount of data is being handled,
for example, large internal tables.

Integration
The SAP memory management concept intends SAP paging to be used only if the ABAP
commands EXTRACT and EXPORT... TO MEMORY... are used.
Compared to the other memory types, SAP paging has the disadvantage that the addresses are not stable.
This means, if a swapped page is reused after a while by the same work process, it no longer has the same
address.

SAP Paging (BC-CST-MM)

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.

User Context
The user context is the data that is specifically assigned to an SAP user. Whenever an SAP user starts a
transaction (an ABAP program), the work process processing the request always requires the user context.

The user context contains name-value pairs that describe a client connected to the server. There is a
unique context for each client, and it lasts only as long as the user is connected to the server. The
following table identifies the context values defined by Windows Media Services.

Structure
Each user can open up to six external

sessions ( System Create Session ).

Note
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.
The user context contains a user-specific area containing user and authorization data, and a session
context for each external session (technical term: emode).
The following figure shows the structure of a user context.

Structure of User Context

Each external session can administrate from its side multiple internal sessions (technical term imode). This
is not explained in detail in this documentation.

Integration
All user contexts are contained in a common resource, the

SAP Extended Memory, which enables a fast

context change.

SAP Roll Area

Definition
The roll area is a memory area with a set (configurable) size that belongs to a work process. It is located in
the heap of the virtual address space of the work process.

Use
When the context of a work process changes, the data is copied from the roll area to a common resource
called theroll file. To prevent repeated copying, another roll buffer is located in between that is part of the
shared memory.

Structure
The roll area consists of 2 segments. The first segment, which can be set with the parameter ztta/roll_first,
is assigned to the work process first as memory. If this is used up, the work process has more memory

assigned to it. The amount of memory is determined by the difference between the
parameters ztta/roll_area and ztta/roll_first.
For more detailed information, please see the platform-specific section under Implementation.

Integration
For technical reasons, the roll area is always the first memory that receives a work process. Only afterwards
can extended memory be requested.

SAP Extended Memory

SAP extended memory is the core of the SAP memory management system. Each SAP work process has a
part reserved in its virtual address space for extended memory.

You can set the size of extended memory using the profile parameter em/initial_size_MB: Extended
Memory Pool Size. Configurable Under Windows, further memory is assigned dynamically as needed,
and you can also set this amount.
The SAP system builds a layer on to the operating system functions for the page management of this
memory. This extended memory is implemented as an unnamed mapped file. This means the address
space uses the paging file or uses the swap space of the operating system as background memory.

Address Stability
You can map the extended memory from the common resource onto any work process, and after onto
another process (see graphic) on the same address in the virtual address space. This is important if you
work with pointers in the ABAP program.

What is Heap Memory?

Heap Memory stores User Context when Extended Memory allocated to a work process gets exhausted and
the work process requires more space to continue. Heap Memory stores contains same type of Data as
Extended Memory. Heap Memory is allocated dynamically according to requirement and not during system
startup. When the workprocess starts using heap area it enters in to PRIV mode.

Private Memory
Other processes cannot use private (heap) memory. After releasing the assigned memory, the operating
system still considers the (virtual) memory as being occupied by the allocating process. These
characteristics of heap memory require that:
1.

The work process can be run in PRIV mode (private) when the local memory is assigned. This means
that the work process is reserved for processing the current user context until the context releases the
work process again when the request has ended. Up to this time point no other user context can be
mapped to the work process.

2.

The work process, if it has used a lot of private memory, is restarted when the user context is
terminated and the local memory is returned. The restart makes the local memory available again for
other processes. The restart occurs if a work process uses more local memory than is defined in the
parameter abap/heaplimit. The mechanism is displayed again there.

For more information, see:

Virtual Address Space of a Work Process

If a dialog work process has used up the roll area assigned to it and the extended memory, private memory
is assigned to the work process. The work process goes into PRIV mode.
In the parameter settings, ensure that not too many dialog work processes are simultaneously in the PRIV
mode, since this lowers system performance.
The other

work process types (background, update, enqueue and spool work processes) are assigned

heap memory after the roll area is used up. Allocating Extended Memory is not useful since no context
change occurs for these processes.

Integration
Automatic Termination of PRIV Mode Processes
If too many dialog work processes run in the PRIV mode in an SAP application server, performance problems
arise. The normal processing of user inquiries is slowed down by the PRIV mode work processes.
The SAP system offers a mechanism that lets you terminate non-active dialog processes in the PRIV mode.
This mechanism helps reduce performance problems.
The mechanism works as follows:
In the PRIV mode, a maximum number (n) of dialog work processes can run without any time restrictions.
To determine this number n, set the value of the profile parameter rdisp/wppriv_max_no. If a value is not
entered, the SAP system determines n using the following formula:
the number (n) is set to the greater of the 2 following values:

Number of dialog work processes minus 5

If more than n dialog work processes are active and the time span set in
parameter rdisp/max_priv_time(default 600 seconds) has elapsed, the transaction for that PRIV process,
which has spent the longest possible time in PRIV mode, is reset.

Virtual Address Space of a Work Process

With 32-bit systems, 4 GB of memory is theoretically available. Depending on the operating system, there is
approximately 2 GB of virtual address space available to a process.
The address space consists of a text segment, a data segment, a dynamically extendible heap, and a
dynamically extendible stack. The heap increases in size from the bottom and the stack increases from the
top, which enables the entire virtual address space to be used.
Specific areas are reserved on the heap for an SAP

Work Process. The size of these areas can be set

using profile parameters. These areas are:

SAP Roll Area

SAP Paging Area

Private Memory

The largest reserved area is located between the heap and stack. This is the

SAP Extended Memory.

The figure below shows how SAP memory areas are mapped to operating system resources.

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

Here are the following types of work processes:

Work Process
Type

Use

Dialog

Executes dialog programs (ABAP)

Update

Asynchronous database changes (is controlled by a COMMIT WORK statement in a dialog

work process)

Background

Executes time-dependent or event-controlled background jobs

Enqueue

Executes locking operations (if SAP transactions have to synchronize themselves)

Spool

Print formatting (to printer, file or database)

Several dialog work processes usually run on one application server. There are usually only one or two other
types of work process.

Structure
A work process consists of a screen processor, the ABAP interpreter, the database interface and the task
handler that calls these programs.

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

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.

Implementation on Windows
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 for 32-bit, and 100000 MB for 64-bit Windows platforms, 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
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:
1.

Roll memory until the limit ztta/roll_first

2.

Extended memory until the limit min {em/address_space_MB, ztta/roll_extension}

3.

Roll memory until the limit ztta/roll_area

4.

Heap memory until the limit abap/heap_area_nondia

The basis for zero administration memory management is a sufficiently large 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.

Allocating Memory for User Contexts

(UNIX)
The memory management system assigns memory to user contexts from the following areas: roll area, SAP
extended memory, and heap memory.
The order of assignment from these memory areas arranges itself according to whether the user context
runs in an SAP dialog work process or in another SAP work process. This enables the SAP system to
optimally use the characteristics of the individual memory types.
When allocating memory, the following characteristics for individual memory types become noticeable.

Memory Type

Characteristics

SAP Roll Area

Sequential memory allocation to several work processes using a relatively slow copying
process

SAP extended
memory

Sequential memory allocation to several work processes using a fast allocation process
Uses swap space

Private Memory

Allocation to a local work process, as required for the running user context in the process
Uses swap space

Process
The flow depends on whether it is a dialog work process or not. Unlike other work process types, dialog
work processes require frequent context changes. Private memory that is linked to a work process is only
assigned if there are no other options.

Allocating Memory for Dialog Work Processes

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

the SAP system.

1.

For technical reasons, the roll area provides the first 100 to 250 KB (depending on the operating
system) for the user context. Additional memory for this initial assignment sets itself according to the
system profile parameter ztta/roll_first. If, for example, ztta/roll_first is set to 1000000(1 MB),

approximately 1.2 MB roll area is provided. If ztta/roll_first is set to 1, only the technically necessary
amount is allocated to roll memory.)
2.

3.

If the memory from the roll area is not sufficient for the user context, more memory is provided from
the SAP Extended Memory. Extended memory is available for the user context until one of the following
conditions is satisfied:

The work process has reached the limit of the SAP extended memory for work processes. This
limit is set in the system profile parameter ztta/roll_extension.

The SAP extended memory is used up. The size of the extended memory pool is set in the
system profile parameter em/initial_size_MB.

If this memory is also insufficient for the user context, more memory is provided from the roll area
until this area is completely used up, or until the limit set in ztta/roll_area is reached. The roll memory
now available sets itself according to the difference between the 2 parameter values ztta/roll_area (total
memory in the roll area) and ztta/roll_first (size of assigned roll memory in step 1).
If the user context still requires additional memory, it is assigned heap memory ( Private

4.

Memory).

Heap memory is available until one of the following situations occurs:

SAP restrictions
Either the limit of the heap memory for dialog work processes is reached (defined in the system
profile parameter abap/heap_area_dia), or the entire heap memory of all work processes for an SAP
application server reaches its limits (defined in parameter abap/heap_area_total).

Operating system limits for allocating memory

The swap space in the host system is used up or the upper limit of the operating system
address space (as determined by the 32-bit architecture) is reached.
Try to avoid these situations at all times. To avoid this situation, you must set
parameterabap/heap_area_total correctly.

Allocating Memory for Other Work Processes

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

1.

The memory is taken from the roll area until the area is used up. The maximum size of the roll area
is set in the system profile parameter ztta/roll_area.

2.

If the roll area is full, heap memory is allocated to the work process. Heap memory is available until
one of the following situations occurs:

SAP restrictions
Either the limit of the heap memory for non-dialog work processes is reached (defined in the system
profile parameter abap/heap_area_nondia), or the entire heap memory of all work processes for
an SAP application server reaches its limits (defined in parameter abap/heap_area_total).

Operating system limits for allocating memory

The swap space in the host system is used up. This situation should never occur (see
Requirements).

Space
3.

Swap

If no more private heap memory can be allocated, a non-dialog work process can use the SAP
extended memory.

Exceptions to this Rule

The allocation sequence described here refers to the standard behavior. You can configure a different
behavior for some platforms:

AIX
If parameter ES/TABLES = SHM_SEGS is set, the allocation sequence for non-dialog work processes is
the same as for dialog work processes (first EM, then Heap).
More information:

Configuration for AIX

Linux
If parameter em/implementation = map is set, the allocation sequence for non-dialog work processes
is the same as for dialog work processes (first EM, then Heap).
More information:

Memory Management on Linux

IBM i and Windows have their own allocations sequences. For more information, see the relevant
platform documentation.

Display and Control Work Processes

Use
Work processes do the majority of the processing of the SAP System. They execute dialog steps in user
transactions, updates, lock administration, etc.
You can also find the term Work Process in the glossary.
You can display a snapshot of the status of the work processes on the application server where you are
logged on. (Choosing Administration System Administration Monitor System Monitoring Process
Overviewor transaction SM50). You must refresh the display to get updated information. The information on
this screen is described in the following section.
The process overview is intended primarily for information-gathering. For example, you can monitor
processes to determine if the number of work processes in your system is adequate, to assess if the
instance is working to full capacity, to gather information for trouble-shooting, or for tuning.

Integration
By choosing System Monitoring Servers, this displays the Overview of the SAP Application Server.
Here, you can further display the work process overview for a particular server in the SAP system by
clicking on the desired server name.

If system load is low, you may notice while using the Process Overview that your requests
appear to execute in only a single work process. The dispatcher is trying to use one work
process for as many dialog steps for one user as possible. This avoids having to reload the
roll area for the user.

Features
Monitoring
The Process Overview displays the following information:
No: The internal ID number of a process. Used to identify messages that belong to a work process in
the system log
Type: Work process types:
DIA work process for executing dialog steps in user transactions
UPD: Update process for making U1 (time-critical) database changes
UP2: Update process for executing U2 (not time-critical) database changes
ENQ for setting and releasing locks on SAP lock objects
BTC for executing background jobs
SPO for spool formatting processes
PID: Process ID of the work process (on the operating system)
Status: Current status of the work process Possible statuses are:
Running (executing a request)
Waiting (idle and waiting for a request)
Hold (held for one user) is not an abnormal state, but a work process can only serve a single user.
If too many processes are in Hold, then system performance suffers. You can then use
the Reasonfield to identify holds that perhaps can be released.
Stopped (aborted; Restart set to No).
Shutdown: Process is stopped due to a shutdown (more information: States of an Application Servers)
Reserved: Process is reserved (more information: Dynamic Work Processes)
Reason: If a work process is in Hold status, the reason is displayed. Typical reasons are: Debugging,
CPIC activity, locks, updates, GUI (system waits for response from the SAPGUI front-end program, for
example, for a remote function call (RFC)). For an overview of the possible parameters, refer to
the F1 help.
You may also see PRIV (PRIVate use) as a reason for holding a work process. PRIV indicates that a work
process is reserved for a single user for memory management use. The work process has exceeded the

limit of the SAP memory that is used by other processes. The process is held as long as the current user
requires local memory.
If more than a certain percentage of work processes are in PRIV hold state, then PRIV transactions are
automatically terminated if the user is not active in the transaction for a set period of time. You can set
this time span in the SAP system profile.
Start/Restart: Indicates whether the process should be automatically restarted if a process ends
prematurely. You can change the restart status of a process by choosing Process Restart after
error Yes/No. Normally, leave Restart set to Yes.
If a work process aborts during its startup, the system automatically sets Restart to No. This measure
protects against endless attempts to restart a process if a database system is not available, or another
serious problem is affecting the system. After correcting the problem, you can change Restart to Yes so
that the system starts the work processes.
Err: Indicates how many times a work process has aborted since the instance has been running. You
can also reset the counter (Edit Process (Menu Option List).
Locked Sem: Specifies the number of semaphores held by the work process.
If the process is holding several semaphores, the numbers are separated by inverted commas. F1 help
provides a list of all semaphores used by SAP.
Active Sem: Indicates the number of the semaphore for which a work process is waiting.
Normally, this field should be empty. If it occurs again after refresh, you can see in the locked
semaphores column whether the required semaphore is being held by another work process. F1 help
provides a list of all semaphores used by SAP.
CPU: Cumulative CPU time since the start of a work process. The time units are seconds and
hundredths of seconds.

Calculating CPU time is onerous. For this reason you have to request this information directly.
Choose List CPU.
Time: Indicates the elapsed time used by a work process for the dialog step that it is currently
processing
Report: ABAP programs or reports that are currently being run.
Cl.: Client for the session that is currently being executed
User: User whose request is currently being processed
Action: Action that is being executed by the current program. The actions that are displayed are those
that are recorded by the SAP performance monitor. The Performance Monitor must be active (SAP
profile parameter stat/level = 1(default)) for actions or database table accesses to be displayed.
Table: If the database is being accessed, this column shows the name of the table being accessed.

Info Area
You can add a further info area to the header area. This info area displays the following information about
the processes:
Total number of work processes
Number of processes of different types specifying how many are free
Number of configurable and dynamic work processes (more information: Dynamic Work Processes)
To show the info area choose List Configuration and select info area.

Administration
The menu offers the following functions:

Control and Check Work Process (Menu Option Process)

Controlling the ABAP Program (Menu Option Program/Mode)

Process Work Process (Menu Option List)

Goto: Here you can display User Info to the user who is currently occupying the work process
or Backtakes you to the last screen (same as the green arrow does).

To manage users, use the User Overview (Display

and Manage User Sessions). In the Process

Overview, you cannot be sure that a user session you want to cancel or delete is still active in the work
process that you have chosen. You could unintentionally affect another user's session.

Memory allocation sequence to dialog work

processes in SAP
This article answers the following queries:

What is the memory allocation sequence to dialog work processes in SAP?

When does a work process go to PRIV mode?

How to avoid or minimize work process going to PRIV mode ?

What are the SAP parameters used to define initial roll area, extended memory, heap memory, roll
area ?
Memory allocation sequence to dialog work processes in SAP :
--------------------------------------------------------------------------------------

1.

Initially , a defined roll area is used. This roll area is defined by the SAP parameter ztta/roll_first.

Usually ztta/roll_first is set to 1 in SAP so that only technically necessary amount is allocated to roll
memory.
If the memory from the initial roll area( i.e. ztta/roll_first) is not sufficient for the user context then
2.

Extended memory is used until the extended memory is full or until the user quota is reached

Extended memory is defined by the SAP parameter em/initial_size_MB and the user quota for dialog
workprocess is defined by the parameter ztta/roll_extension_dia.
If this memory is also not sufficient, then
3.

The rest of the roll area is used. This roll area is defined by SAP parameter ztta/roll_area.

Once this is also fully occupied then

4.
The system is forced to use local heap memory (Private memory). Then the work process goes into
PRIV mode
Heap memory is available until one of the following occurs :
Either the limit of the heap memory for dialog workprocesses is reached (abap/heap_area_dia) or the entire
heap memory of all work processes(abap/heap_area_total) for an application server reaches its limit.
Operating system limit for allocation of memory
The swap space in the host system is used up or the upper limit of the operating system address space is
reached.

The memory allocation strategy for dialog work processes, aims to prevent work processes from allocating
R/3 heap memory and thus entering PRIV mode.
When a work process enters PRIV mode, it remains connected to the user until the user ends the
transaction. Most of the time, we should try to avoid the situation of work process going into PRIV mode for
better performance of the SAP system. This can be done by optimally defining abap/heap_area_total
parameter.

abap/heap_area_dia: Heap Memory Limit

for Dialog Work Processes
Use
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.

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

Functions of the SAP Memory

Management System
Prerequisites
You must be familiar with basic terminology related to memory management.
You can find a summary of the terms in Memory Management: Basic Terms.

Features
An application runs in an SAP work process where an ABAP program is normally executed. The process
requires memory to do this, which is allocated to the process by the memory management system. The
order in which the work process is assigned the memory type depends on the work process type, either
dialog or non-dialog (see SAP Memory Types), and the underlying operating system.
The location of the various memory areas in the virtual address space is explained in Virtual Address Space
of a Work Process.
The user context area that allows direct access can be extended as required when the size of the user
context increases. For dialog work processes, the data of the user context, including internal tables is
located in this expanded area. You can therefore access all the data in the user context. Only data of
types extract andexport to memory still remain in SAP Paging.
The SAP Roll Area is used for the initial memory assigned to a user context, and (if available) for additional
memory if the expanded memory is full.
The following diagram displays the memory types that can be assigned to R/3 work processes on the SAP
and operating system level. Here are the most important system profile parameters that control the
availability of the memory types.

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

Roll-in: cross-user data is rolled in from the common resource in the work process (and is processed
there).

Roll-out: User-specific data is rolled out from the work process in the common resource (after the
dialog step has ended).

The common resource stands for the different SAP memory types.

Using the VM Container

If the SAP Virtual Machine Container is active in your system, Java programs can also be executed. Memory
management has been extended for this.