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
R/3 memory allocation explains what the different memory areas are used for.
After the demonstration and exercise, the topic Implementing R/3 extended memory compares memory management for different hardware platforms:
UNIX versus Windows NT
32 bit versus 64 bit architecture
This unit does not explain how large you should make the various memory areas.
Users need two kind 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)
Physical and Virtual Memory
Maximum virtual memory <= Physical memory + operating system
swap space.
Unlike physical memory, virtual memory can be allocated. The os determines if the allocated memory area resides in the physical memory or in the os swap space.
Depending on the os, the maximum size of the virtual memory may vary between the size of the os swap space and the sum of physical memory and os swap space.
R/3 buffers contain global objects for all users and work processes, such as programs and customizing tables.
Shared memory is associated with all the processes of one instance. It is allocated at instance startup.
Extended memory contains user contexts – that is, objects associated with individual users, such as variables, lists and internal tables.
Heap memory – allocated on demand
Contains user contexts, for example, when extended memory is full
Is allocated and released on demand
R/3 paging memory contains:
ABAP objects such as extracts
Context-independent objects such as exports.
The six R/3 memory areas are
Buffers
Extended memory
Heap memory
Roll memory
R/3 paging memory – not to be confused with os paging!
Local work process memory
R/3 Memory allocation concepts
In and R/3 system, many front end users are connected to one or more application servers. The work that users request from the system is performed in the work processes. Normally there are fewer work process than front end users.
A work process is dedicated to a front end 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 course of their work in dialog work process, users accumulate various piece of data, such as pointers to programs they are using. This accumulated data is called the “User context”.
Roll in/ Roll out process
Roll area and paging area.
Roll area in which User context objects such as authorizations, set/get parameters, internal tables and report lists are available.
Paging area stores the application program data that corresponds 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.
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).
The user data processed in the work processes is stored in two areas:
The roll file and its associated buffer.
The page file and its associated buffer
User contexts are not only stored in roll files and the corresponding buffers.
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 overload caused by large roll – in or roll-out tasks.
Allocation sequence for dialog work process
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.
Extended memory enables the data to be stored in your system, where it is efficiently accessed by pointers rather than a copy process.
The extended memory per user may vary from 1 MB to several 100 MB.
When the extended memory is full or until the user quota is reached…
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.
The remaining portion of the 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.
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 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.
Since R/3 architecture uses a limited number of work processes to satisfy a larger number of front end users, other users suffer when a user goes in to PRIV mode.
If several users go into PRIV mode, they can work well, but other users can hardly work at all.
Data in R/3 roll memory is copied during context switch.
Data in R/3 extended memory is mapped during context switch.
Data in R/3 heap memory can never leave the work process. If heap memory is allocated, the work process is exclusively assigned to one user in PRIV mode.
Note: the sequence in which memory is used by work processes is not determined by the amount memory initially allocated. Thus, while the entire roll memory is allocated on work process start, it is not initially used up completely.
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.
Allocation sequence for non-dialog work process
Freeing heap memory
If the heap memory consumption of a work processes exceeds abap/heaplimit, after ending the transaction, the heap memory is automatically released and the wp restarted to release the swap space.
OS swap space is saved through parameter abap/heaplimit
Memory management parameters
Ztta/roll_first: Defines the first part of the roll area that is allocated to a dialog process.
Ztta/roll_area: Defines the total roll area per work process.
Rdisp/roll_SHM: Defines the size of the roll buffer.
Rdisp/roll_MAXFS: Defines the size of roll buffer and roll file.
Em/initial _size_MB: Defines the fixed size of extended memory.
Ztta/roll_extension: Defines the user quota for extended memory.
Abap/heap_area_dia: Defines the limit for the amount of local memory allocated to dialog work processes.
Abap/heap_area_nondia: defines the limit for the amount of local memory allocated to non-dialog work processes.
Abap/heap_area_total: defines the total amount of heap memory allocated to all work processes.
Here we can see that the extended memory set is completely in use.
Call the Setups/Tune buffers monitor (ST02) and choose detail analysis menu-> SAP memory -> Mode list. Here we can see that several work processes need to allocate R/3 heap memory.
The Work process Overview (SM50) shows that the work processes that need to allocate R/3 heap memory enter PRIV mode. These work processes are locked to one particular user.
Implementing R/3 extended memory
—————————————————————–
Zero Administration Strategy
Since on NT the parameter em/max_size_MB has a default value of 20,000, the size of R/3 extended memory is limited by the size of the address space of the NT paging file.
The parameter em/initial_size_MB is operating system dependent in that it is restricted by the address space of the work process.
For 32 bit architecture, address space is < 4 GB (in some operating systems even smaller).
For 64 bit architecture, the address space is <1.8 * 10 18 bytes.
SAP recommendations
For 32 bit architecture using em/initial_size_MB <=2GB, (even less for some os).
The amount of extended memory should be proportionate to the amount of physical memory.
The default value of ztta/roll_extension is 2 000 000 000 begin_of_the_skype_highlighting 2 000 000 000 end_of_the_skype_highlighting, which effectively deactivates this parameter. The limit for the user quota is given by the parameter em/address_space_MB.
One instance start, the extended memory is allocated by em/initial_size_MB
With NT, the amount of extended memory can increase dynamically upto em/max_size_MB, as long as the maximum virtual memory (that is , physical memory + swap space) is not yet exhausted.
There are no address space restrictions for extended memory, which is restricted only by the maximum virtual memory.
With NT, the recommendations for R/3 extended memory are more generous than under UNIX. However, parameter em/address_space_MB determines the user quota – that is the amount of R/3 extended memory, which may be used by one single user context.
The amount of extended memory should be proportionate to the amount of physical memory.
Hardware Capacity Verification
From Users point of View
Lengthy response time for transactions
From the systems point of view
CPU utilization is nearly 100%
High average number of processes waiting for CPU (load average)
High paging rates
Lengthy disk response times
Lengthy network response times – ping
Analyzing Hardware bottlenecks Road map – 1
Operating System Monitor – ST06
- CPU idle < 20% ?
- i. Is there CPU capacity on other servers that is idle?
- 1. Redistribute R/3 work processes and users.
- ii. Operating system monitors – ST06 – Top CPU Processes
- 1. R/3 work processes with high CPU utilization?
- a. Work process overview – SM50 or Systemwide work process overview – SM66
- i. Detailed analysis of report or transaction
- 2. Database processes with high CPU utilization?
- a. Database process monitor – ST04
- b. Detailed analysis of SQL Statements
- 3. External processes with high CPU utilization?
- a. Stop or redistribute.
If there is a CPU bottleneck:
- If possible, redistribute load to other servers.
- To find out which processes are using most CPU, in the OS Monitor choose Detail analysis menu -> Top CPU processes. If the processes have high CPU utilization, proceed as follows:
- For R/3 work processes (‘disp + work’): Using the process ID indicated in Top CPU processes, identify the corresponding program name and user name in the Work process overview – SM50.
- For database processes – identify corresponding long running SQL statements in the Database Process Monitor. To access this monitor, call transaction ST04 (database overview), and choose Detail analysis menu.
- For external processes, find out whether the process can be stopped or redistributed.
Hardware analysis roadmap – 2
- Operating system monitor – ST06
- High paging rate (>20% of RAM per hour)?
- i. Memory capacity free on other servers?
- 1. Redistribute R/3 work processes and users
- ii. File system cache > 10 % of RAM?
- 1. Reduce file system cache
- iii. Setups/Tune buffers monitor – ST02 : Mode list
- 1. Programs / Transactions with high memory consumption.
- a. Detailed analysis of report or transaction.
- In the OS monitor – ST06, note the amount of memory indicated beside Physical memory available .
- Compare this figure with the paging rate.
- To obtain the paging rate, dbl click Pages in/s. The paging rates for the last 24 hours are displayed in the columns Paged in [Kb/h] and Paged out [Kb /h].
- If 20% of the total amount of physical memory is greater than the amounts indicated in these columns, you can normally be sure there is no memory bottleneck.
- If there is a memory bottleneck:
- If possible, redistribute load to other servers.
- Check the size of the file system cache. If necessary reduce the file system cache to < 10 % of the total physical memory.
- To identify users in their programs with high memory consumption, call the mode list for the extended memory. To do this, in the Setups/Tune buffers monitor – ST02, choose Detail analysis menu -> SAP memory -> Mode list.
Hardware Analysis Road map – 3
- Work load monitor – ST03N
- Wait time > 10% of response time
- i. General performance problem
- 1. High database time: database time >40% (response time – wait time)
- a. Detailed analysis of database
- 2. Processing time > CPU time * 2
- a. Detailed analysis of hardware bottleneck
- 3. Load time > 50 ms
- a. Detailed analysis of R/3 memory config. (program buffer too small?)
- 4. Roll in/ Roll out time > 20 ms
- a. Detailed analysis of R/3 memory configuration (problems with extended memory or roll buffer?)
This part of road map guides you in analyzing workload data when looking for hardware bottlenecks:
- Call the workload monitor – ST03N. In expert mode, choose detailed analysis -> last minute load. Select the current application server.
- in the statistics displayed, a hardware bottleneck may be indicated if the following figures are significantly high:
- Average wait time
- Average load time and average roll time
- Average database time
A high average wait time means all programs are running slowly and blocking the work process for a longer time. A high average load time and high average roll time mean that loading and rolling are slow. A high average database time means the database is running slowly and may indicate a hardware bottleneck on the database server.
From the statistics displayed, you can calculate the processing time as equivalent to the response time – the sum of wait time, database time, load time, roll time and enqueue time. A large processing time means the work processes are waiting for CPU while processing ABAP programs.
To calculate the processing time :
Processing time = Response time – wait time – Database time – Roll time – load time
= 6073 – 1562 – 2254 – 248 – 169 = 1840 ms
The processing time is thus more than twice the average CPU time:
1840 (processing time) / 546 (average CPU time) = 3.4
This indicates a resource bottleneck. In this example, the CPU bottle neck is caused by external operating system process consuming CPU.
Notice the large wait time, database time and load time.
To check for problems at operating system level, use the operating system monitor (transaction ST06). Notice high % CPU utilization: user 96%, system 4% , idle 0%.
Why is the CPU usage at almost 100% capacity?
From the operating system monitor – ST06, choose detail analysis menu -> Top CPU processes.
The DR_WATSON processes are not related to R/3 system or to the database and therefore are external processes.
One way of tuning the system in this case is to terminate the external processes that are creating an unnecessary load on the CPU.
Verify the solution by terminating the external processes and restarting the workload simulation.
Typically not all external processes but only the following runs on the database server:
R/3 work processes of the central instance.
The database processes required for the database.
These processes have to share the available CPU’s.
As the database server is being accessed from all application servers, the performance associated with the database access is critical for overall system performance.
Optimizing Memory configuration – 1
Memory for database (once per R/3 system)
Rule of thumb: 20% of the total physical memory (of all servers)
Memory of R/3 buffers (once per R/3 instance)
Approx. 500 to 800 MB (depends on applications used)
Memory for R/3 work processes
Approx. 12 MB per work process
R/3 extended memory
Approx. 10 to 20 MB per user
Optimizing Memory configuration – 2
Physical main memory (RAM)
Virtual memory should be < 2* the physical memory
Swap space
3 times physical memory
At least 2 GB
Workload
Number of active users
R/3 applications used
To check R/3 virtual memory allocation for a specific instance, in the Setups/Tune Buffers monitor- ST02, choose Detail analysis menu -> Storage. The total memory allocated for this instance is displayed beside virtual memory allocated. To this figure, add the virtual memory allocated to any other R/3 instance or database running on this server.
Compare the total virtual memory with the total physical memory. If the ratio is less than 3:2, you can normally be sure that there is no memory bottleneck.
If the ratio is greater than 3:2, check how much of the allocated virtual memory is really being used, especially in extended memory and the program buffer. To do this, in the initial screen of the transaction ST02, look at the columns Max. use [ KB] and In memory [KB].
Configuring CPU
For database : Rule of thumb : 10-30% of the total CPU of all servers.
Ensure that there is never a CPU bottleneck on the database server.
For update processing : Rule of thumb : 10 – 20% of the total CPU for all servers.
For dialog/background processing : No general recommendation for CPU per user.
CPU required depends on applications used.
Example on a server with 2GB memory :
R/3 Buffers (without roll and paging) : 700 MB
Program buffer: 500 MB
R/3 table buffers: 110 MB.
Extended, roll and paging in shared memory 1500 MB
18 work process 120 MB
Virtual memory allocated for R/3 2.3 GB
Memory allocated for database 500 MB
The following R/3 parameter settings are configured in the R/3 system used in this course:
Nametab buffers:
- rsdb/ntab/entrycount: 30 000
- rsdb/ntab/ftabsize: 30 000
- rsdb/ntab/irdbsize: 4000
- rsdb/ntab/sntabsize: 2500
Program / CUA/ presentation buffers:
- abap/buffersize: 500 000
- rsdb/cua/buffersize: 5000
- zcsa/presentation_buffer_area: 20 000 000
- sap/bufdir_entries: 4500
Table buffers:
- zcsa/table_buffer_Area: 70 000 000
- rtbb/buffer_length: 40 000
