Brief summary of

SAP Memory Management

Physical and virtual memory - Memory refers to virtual memory, which the operating
system manages either in the physical main memory or in the swap space.
The maximum amount of virtual memory that can be allocated is depending on two
factors – (a) Physical hardware restrictions i.e. all processes together cannot
allocate more memory than the sum of the physical main memory and the available
swap space and (b) each individual process cannot allocate more memory than the
maximum addressable memory area i.e. address space permitted by O/S.
Local and shared memory – Local memory is always allocated to just one O/S process
i.e. only this one process can write or read from this memory area. On the other
hand, Shared memory is accessible to multiple O/S processes. All SAP Buffers reside
in shared memory as all SAP work processes of an SAP instance have to write and
read from SAP buffer. Additionally, Local memory is created for every work process.
Virtually Allocated Memory = Local Memory + Shared Memory.
If there are several SAP instances or one SAP instance and one database instance on
a computer, the processes of one instance can always only access the shared memory
of its own instance but not the shared objects of other instances.
Memory Management
in the context of SAP
User Context – A transaction generally extends over several transaction steps. Data
such as variables, screen lists, internal table is generated during these steps and
stored in the application server memory which is referred as User Context.
User context are stored in SAP roll memory, SAP extended memory, or SAP heap
memory.
Session – When one opens a new session then a new user context is created. The data
from the transactions executed in the two sessions and is stored independently in
different memory areas. Sessions that are explicitly opened by the user is called
external session, where as sessions that are opened implicitly by ABAP program from
another program, for which a new user context is created is called internal
session.
SAP roll memory – The initial part of user data is stored in the local roll area of
the work process. As it is a logical memory, each SAP work process can access only
its roll area.
At the end of transaction step, the user exits the work process so that another
user can use this work process. The content of user’s local work process roll area
has to be backed up and that’s why it is copied to the shared roll area.
The shared roll area is either a memory area in the shared memory of the
application server or a file on the application server’s hard drive.
The shared roll area is accessible to all of the instance’s work process. The
process of copying the local roll memory to the shared roll area is called roll
out.
If the user is assigned a different work process in the next transaction step, the
user context is copied from the shared roll area to the local roll area of the new
work process and the user can continue working with the old data. It is called roll
in.
Profile parameters used to configure the size of SAP roll memory are as follows:
ztta/roll_area - size of the local SAP Roll area in the work process and applies
equally to all work process types.
rdisp/ROLL_SHM - size of SAP roll Buffer
rdisp/ROLL_MAXFS - size of entire shared SAP roll area (roll buffer +roll file)
SAP extended memory – User context are generally stored in SAP extended memory. It
is allocated as shared memory. All instance work processes can edit the stored user
contexts directly.
The entire user context is not copied when rolled in to the local memory of the
work process, only the addresses indicating where the user context is located in
SAP extended memory are copied. i.e. pointers. The volume of data copied in a roll-
in or roll-out is reduced considerably by using SAP extended memory, which makes
the roll process faster.
Profile parameters used to configure the size of SAP extended memory are as
follows:
em/initial_size_MB - size of SAP extended memory allocated when the SAP instance
starts up
em/blocksize_KB - SAP extended memory is split internally into blocks of size. The
default block size is 1,024 KB.
ztta/roll_extension - maximum size of a user context in the SAP Extended memory.
SAP heap memory – The next memory area where user contexts can be stored is known
as SAP heap memory. Whereas the roll area allocation is already fixed at the time
of startup, heap memory is variably allocated as local memory as required. i.e.
when the user context increases a certain size.
Profile parameters used to configure the size of SAP heap memory are as follows:
abap/heap_area_dia and abap/heap_area_nondia – define the size of SAP heap memory
for dialog and non dialog work processes respectively.
abap/heap_area_total – it specifies the total SAP heap memory that can be allocated
by all work processes.
abap/heap_area – maximum possible value for this is approx 2 GB.

Sequence for memory Allocation

When a transaction starts, the user data is stored in local roll area of the work
process upto a size of ztta/roll_first which is set to 1 byte. If the size of user
data increases, the data is stored in SAP extended memory. If extended memory is
used up, the remainder of local roll area is used upto the size of ztta/roll_area.
If the user data still grows, the work process allocates SAP heap memory as
required. The disadvantage of using heap memory is that it is not local and cannot
be copied to a shared memory area. In the case of heap memory, user data cannot be
transferred to another work process. The work process is assigned exclusively to
one user. This state is referred as PRIV mode which we can see in the work process
overview screen.
Now if the value of abap/heap_area_dia or abap/heap_area_total is reached, the
program will terminate.