SAP Memory Management
- ztta/roll_first = 20KB
- ztta/roll_area = 1MB
- ztta/roll_extension = 2GB
- abap/heaplimit = 8GB
- abap/heap_area_dia = 4GB
- abap/heap_area_nondia = 4GB
Memory allocation sequence to dialog work processes in SAP. This article answers the following questions-:
- 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?
Memory allocation sequence to Dialog work process in SAP
- 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 [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 work process is defined by the parameter “ztta/roll_extension_dia”. If this memory is not sufficient then,
3. The rest of the roll area is used. This roll area is defined by SAP parameter “ztta/roll_area _ ztta/roll_first”
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 work processes is reached [abap/heap_area_dia] or the entire heap memory of all the work processes [abap/heap_area_total] for an application server reaches its limit.
- Operating system limit of allocation of memory.
- The swap space in the host system is used up or the upper limit of the OS address space is reached.
The work process cannot be terminated by the parameter “rdisp/max_wprun_time” [PRIV] when a work process enters PRIV mode, it remains connected to the user until the user ends the transactions or it is timed out by the system due to the memory or explicitly logged out using SM04/DPMON.
Question-: Users complain that they could not access the system [globally] users are encountering the hour glass mode, SM50/SM66/SM21 are not accessible.
- Check the system status using DPMON/SAPMMC [download sapmmc for unix/windows]
- Identify the process that has been logged for longer time.
- Kill the process [if dpmon could not kill] then use task manager or kill command on unix.
Restrict the processes that goes into wp PRIV mode by using parameter “rdisp/wppriv_max_no=1 or 2”
rdisp/max_priv_time=60 secs to terminate the processes that are in PRIV mode.
NOTE-: The long memory programs/ transactions can be split into Variants (monthly) and schedule to run the background during off peak hours.
- It is used to configure the physical memory, if more than one instance is configured.
- If there is only one instance then by default it takes the complete memory.
- ST02 — for system memory
- SM04 — for user memory
- ST03 — programs/transaction memory
- SM66 — process memory
- “top” command in Linux to see all the processes, used memory, free memory etc.
Task manager in Window
If the memory is not released then we use command “ipcrm” or use “cleanipc” to release the memory blocked at OS level.
- The system logs by default in usr/sap/SID/DVEBMGS00/log/SLOG00 without any initiation.
- These logs are displayed in SM21 [These are cycled automatically when they reach a limit]
- The developer traces are logged in work directory by default to work directory [/usr/sap/SID/DVEBMGS00/work]
These are explicitly switched on the system to trace/track either a user missing authorization, en queue issues, rfc issues, sql issues, kernel issues etc.
Select the trace and switch on. Specify the user, process etc
- ST05 is used to identify the expensive SQl statements and explain about the SQL statements.
Can refer to different SAP Notes for more detailed information.
Single world for it !!! Super
Thanks for your document... but memory management has change since NW 7.4
Memory Management simplifications in ABAP Kernel 7.4 => http://go.sap.com/documents/2015/07/10a81ddf-557c-0010-82c7-eda71af511fa.html
Small comment to memory drawing and reference to parameters:
abap/heaplimit is not a limitation to the heap size.
This was a parameter introduced as a "tripwire" that should indicate at which level of memory consumption a work process should be cleaned and memory released. Normally this limit would be much smaller than the heap size to avoid that all WP's claim and hold max heap memory.
Documentation from RZ11
This value specifies the memory amount in bytes. When this amount is exceeded, a work process is restarted after completing a transaction step. In a work process, heap memory (malloc) can be allocated for a user context. 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.
In the drawing the heaplimit is set to 8 GB and worst case each of your WP could then claim and hold 8GB memory at OS level before they are restarted! - hope you do not have too many wp's 😉
It is vital that your WP's get restarted in order to free up the memory for OS.
I have tried to keep the heaplimit (as recommended) low, but my experience is that the heaplimit parameter seldom or ever works correctly (kernel dependent). WP's might be claiming way more memory and do not perform the restart according to heaplimit which should release memory properly.
A workaround for this missing feature is to use the rdisp/wp_auto_restart parameter to release WP allocated memory. Previously this was an undocumented feature, but is documented in newer releases.
Very good blog!