Memory Management
Posted:
R/3 memory areas introduces the various R/3 memory areas, which may be physically located in one
or more of the following:
Local memory
Shared memory
File system
Users need two kinds of memory:
R/3 buffers
Memory accessible to all users, for:
Programs
Table and field definitions
Customizing tables
User context
Memory attached to individual users, for:
Variables, lists, internal tables
Administrative data (such as authorizations)
Unlike physical memory, virtual memory can be allocated. The operating system determines if the
allocated memory area resides in the physical memory or in the operating system swap space.
Depending on the operation system, the maximum size of the virtual memory may vary between the
size of the operating system swap space and the sum of physical memory and operating system swap
space.
The six R/3 memory areas are:
Buffers
Extended memory
Heap memory
Roll memory
R/3 paging memory
Not to be confused with operating system paging!
Local work process memory
User Context Data:
In an R/3 system, many frontend users are connected to one or more application servers. The work
that users request from the system is performed in work processes. Normally, there are fewer work
processes than frontend users.
A work process is dedicated to a frontend user only while a specific dialog step is being processed by
the application server. A user can be dispatched to one work process in one dialog step, and to
another work process in the following dialog step. Over the course of time, users are dispatched to
different work processes.
In the course of their work in dialog work processes, users accumulate various pieces of data, such as
pointers to programs they are using. This accumulated data is called the "user context". A user
context enables, for example, the material number you are working on to be remembered by the
system and proposed as the default in a following transaction.
Roll Out (1)
The mechanism known as a "roll out" ensures that when user 2 needs to use the work process which
has just been used by user 1, the user context data of user 1 is not be lost or overwritten.
Roll Out (2)
The roll out saves the user context data for the dialog user when he or she exits the work process.
Roll In
Work process 1 is occupied by another user. When user 1, who was formerly working in work
process 1, is therefore dispatched to work process 2, the user context data is copied into work process
2 by the mechanism known as a "roll in". User 1 can thus continue from where he or she stopped in
the earlier work process.
Roll Area and Paging Area
The data processed in work processes is stored in two memory areas:
The roll area, in which user context data is stored. User context data may include pointers to
active programs, set/get parameters (related to the most recent input of the user), authorizations,
internal tables, and report lists.
The paging area, which stores the application program data that correspond to specific ABAP
commands including EXTRACT, IMPORT TO MEMORY, EXPORT FROM MEMORY, and
CALL TRANSACTION.
The size of these areas is configurable using R/3 profile parameters.
Roll Buffer and Paging Buffer
Where there is buffer space available, the roll area and the paging area are held in the respective
buffers in the application servers. When there is not sufficient buffer space, the roll area and the
paging area must be stored in the respective physical disk files (roll file and paging file).
Thus, the user data processed in work processes is stored in two areas:
The roll file and its associated buffer
The page file and its associated buffer
R/3 Extended Memory
User contexts are not only stored in roll files and the corresponding buffers. As of R/3 Release 3.0,
they are primarily stored in R/3 extended memory.
In R/3 extended memory, a large area of memory shared by all available work processes can be
accessed through pointers. Using extended memory as well as roll files thus reduces the amount of
copying from roll areas that is required during user context switches, and avoids the overhead caused
by large roll-in or roll-out tasks.
In R/3 memory management:
Work processes serve a large number of frontend users
Each work process must be capable of loading the user context data for successive frontend users
The roll data and paging data is copied to the roll buffer and paging buffer and the corresponding files when a user leaves the work process.
R/3 extended memory uses mapping instead of copying and therefore allows:
Fast access to internal tables and lists through pointers
Quick context switches
Usage of hardware with large memory
Reduced load on CPU and disk
R/3 extended memory requires sufficient physical memory
Allocation Sequence for Dialog WPs (1)
To keep the usage of the roll area to a minimum and make more use of extended memory, only a
small portion of the roll area is used initially. The size of this portion is set by the parameter ztta/roll_first.
Note: Independent of parameter ztta/roll_first, there is a minimum amount of roll area that is always
used. For example, if ztta/roll_first is set to 1, not just one byte is allocated, but the minimum amount required for administrative data. As of R/3 release 4.6, this amount is approximately 170KB.
Allocation Sequence for Dialog WPs (2)
Extended memory enables the data to be stored in your system, where it is efficiently accessed by pointers rather than by a copy process.
The extended memory per user may vary from 1 MB to several 100 MB.
Allocation Sequence for Dialog WPs (3
... the extended memory is full
or ...
Allocation Sequence for Dialog WPs (4)
The user quota defines the maximum amount of R/3 extended memory that can be used by any one
user, and is set with the parameter ztta/roll_extension.
The user quota thus prevents one user from occupying all available extended memory.
Allocation Sequence for Dialog WPs (5)
The remaining portion of R/3 roll memory is used when the system can no longer allocate R/3
extended memory, either because R/3 extended memory is full or because the quota has been reached.
The reason for using the remaining portion of R/3 roll memory is to avoid using heap memory, which is local memory, and avoid entering PRIV mode (see below).
Allocation Sequence for Dialog WPs (6)
If the work process requires still more space after using up all available roll area and extended memory, the system is forced to allocate R/3 heap memory locally.
Heap Memory and PRIV Mode (1)
Heap memory allocated by one work process is not accessible to any other work process. This means that a user is unable to continue the transaction in a different work process.
The user is now effectively locked to the work process. This situation is called PRIV mode.
Heap Memory and PRIV Mode (2)
A dialog process that was forced to allocate R/3 heap memory automatically enters PRIV mode.
While a user is in a transaction which caused the work processes to enter PRIV mode, no other user can access the work process.
Since R/3 architecture uses a limited number of work processes to satisfy a larger number of frontend users, other users suffer when a user goes into PRIV mode.
If several users go into PRIV mode, they can work well, but other users can hardly work at all.
Freeing Heap Memory (1)
Heap memory is released after use
Freeing Heap Memory (2)
But used swap space is not freed by the operating system
Freeing Heap Memory (3)
If the heap memory consumption of a work processes exceeds abap/heaplimit, after ending the
transaction, the heap memory is automatically released and the work process restarted to release the
swap space.
Insufficient Extended Memory
The parameter settings for roll memory and extended memory allocate only a small amount of
memory and thus force the work process to allocate heap memory too soon.
Sufficient Extended Memory
To avoid the problem of insufficient extended memory, you may need to increase the size of the
extended memory.
or more of the following:
Local memory
Shared memory
File system
Users need two kinds of memory:
R/3 buffers
Memory accessible to all users, for:
Programs
Table and field definitions
Customizing tables
User context
Memory attached to individual users, for:
Variables, lists, internal tables
Administrative data (such as authorizations)
Unlike physical memory, virtual memory can be allocated. The operating system determines if the
allocated memory area resides in the physical memory or in the operating system swap space.
Depending on the operation system, the maximum size of the virtual memory may vary between the
size of the operating system swap space and the sum of physical memory and operating system swap
space.
The six R/3 memory areas are:
Buffers
Extended memory
Heap memory
Roll memory
R/3 paging memory
Not to be confused with operating system paging!
Local work process memory
User Context Data:
In an R/3 system, many frontend users are connected to one or more application servers. The work
that users request from the system is performed in work processes. Normally, there are fewer work
processes than frontend users.
A work process is dedicated to a frontend user only while a specific dialog step is being processed by
the application server. A user can be dispatched to one work process in one dialog step, and to
another work process in the following dialog step. Over the course of time, users are dispatched to
different work processes.
In the course of their work in dialog work processes, users accumulate various pieces of data, such as
pointers to programs they are using. This accumulated data is called the "user context". A user
context enables, for example, the material number you are working on to be remembered by the
system and proposed as the default in a following transaction.
Roll Out (1)
The mechanism known as a "roll out" ensures that when user 2 needs to use the work process which
has just been used by user 1, the user context data of user 1 is not be lost or overwritten.
Roll Out (2)
The roll out saves the user context data for the dialog user when he or she exits the work process.
Roll In
Work process 1 is occupied by another user. When user 1, who was formerly working in work
process 1, is therefore dispatched to work process 2, the user context data is copied into work process
2 by the mechanism known as a "roll in". User 1 can thus continue from where he or she stopped in
the earlier work process.
Roll Area and Paging Area
The data processed in work processes is stored in two memory areas:
The roll area, in which user context data is stored. User context data may include pointers to
active programs, set/get parameters (related to the most recent input of the user), authorizations,
internal tables, and report lists.
The paging area, which stores the application program data that correspond to specific ABAP
commands including EXTRACT, IMPORT TO MEMORY, EXPORT FROM MEMORY, and
CALL TRANSACTION.
The size of these areas is configurable using R/3 profile parameters.
Roll Buffer and Paging Buffer
Where there is buffer space available, the roll area and the paging area are held in the respective
buffers in the application servers. When there is not sufficient buffer space, the roll area and the
paging area must be stored in the respective physical disk files (roll file and paging file).
Thus, the user data processed in work processes is stored in two areas:
The roll file and its associated buffer
The page file and its associated buffer
R/3 Extended Memory
User contexts are not only stored in roll files and the corresponding buffers. As of R/3 Release 3.0,
they are primarily stored in R/3 extended memory.
In R/3 extended memory, a large area of memory shared by all available work processes can be
accessed through pointers. Using extended memory as well as roll files thus reduces the amount of
copying from roll areas that is required during user context switches, and avoids the overhead caused
by large roll-in or roll-out tasks.
In R/3 memory management:
Work processes serve a large number of frontend users
Each work process must be capable of loading the user context data for successive frontend users
The roll data and paging data is copied to the roll buffer and paging buffer and the corresponding files when a user leaves the work process.
R/3 extended memory uses mapping instead of copying and therefore allows:
Fast access to internal tables and lists through pointers
Quick context switches
Usage of hardware with large memory
Reduced load on CPU and disk
R/3 extended memory requires sufficient physical memory
Allocation Sequence for Dialog WPs (1)
To keep the usage of the roll area to a minimum and make more use of extended memory, only a
small portion of the roll area is used initially. The size of this portion is set by the parameter ztta/roll_first.
Note: Independent of parameter ztta/roll_first, there is a minimum amount of roll area that is always
used. For example, if ztta/roll_first is set to 1, not just one byte is allocated, but the minimum amount required for administrative data. As of R/3 release 4.6, this amount is approximately 170KB.
Allocation Sequence for Dialog WPs (2)
Extended memory enables the data to be stored in your system, where it is efficiently accessed by pointers rather than by a copy process.
The extended memory per user may vary from 1 MB to several 100 MB.
Allocation Sequence for Dialog WPs (3
... the extended memory is full
or ...
Allocation Sequence for Dialog WPs (4)
The user quota defines the maximum amount of R/3 extended memory that can be used by any one
user, and is set with the parameter ztta/roll_extension.
The user quota thus prevents one user from occupying all available extended memory.
Allocation Sequence for Dialog WPs (5)
The remaining portion of R/3 roll memory is used when the system can no longer allocate R/3
extended memory, either because R/3 extended memory is full or because the quota has been reached.
The reason for using the remaining portion of R/3 roll memory is to avoid using heap memory, which is local memory, and avoid entering PRIV mode (see below).
Allocation Sequence for Dialog WPs (6)
If the work process requires still more space after using up all available roll area and extended memory, the system is forced to allocate R/3 heap memory locally.
Heap Memory and PRIV Mode (1)
Heap memory allocated by one work process is not accessible to any other work process. This means that a user is unable to continue the transaction in a different work process.
The user is now effectively locked to the work process. This situation is called PRIV mode.
Heap Memory and PRIV Mode (2)
A dialog process that was forced to allocate R/3 heap memory automatically enters PRIV mode.
While a user is in a transaction which caused the work processes to enter PRIV mode, no other user can access the work process.
Since R/3 architecture uses a limited number of work processes to satisfy a larger number of frontend users, other users suffer when a user goes into PRIV mode.
If several users go into PRIV mode, they can work well, but other users can hardly work at all.
Freeing Heap Memory (1)
Heap memory is released after use
Freeing Heap Memory (2)
But used swap space is not freed by the operating system
Freeing Heap Memory (3)
If the heap memory consumption of a work processes exceeds abap/heaplimit, after ending the
transaction, the heap memory is automatically released and the work process restarted to release the
swap space.
Insufficient Extended Memory
The parameter settings for roll memory and extended memory allocate only a small amount of
memory and thus force the work process to allocate heap memory too soon.
Sufficient Extended Memory
To avoid the problem of insufficient extended memory, you may need to increase the size of the
extended memory.