- SAP Managed Tags:
Are you new to SAP Memory Management (MM) on Windows Server and want to learn the basics? In this paper, we’ll give you an overview of how to deal with physical and virtual memory, what segments the SAP Memory Management consists of, their profile parameters and work processes (WPs), and so on.
Physical und Virtual Memory of the Windows Operating System
One of the most complex and difficult tasks the Windows Server Operating System (OS) faces is how to manage the limited physical memory (RAM) of the server and how to implement the illusion of having a much larger virtual memory used by the running applications. This concept is called “paged virtual memory”. Processes like the work processes (WPs) of the Application Server ABAP (AS ABAP) access memory through their assigned virtual memory address space managed by the Windows Virtual Memory Manager.
The available virtual memory is the sum of existing RAM and the size of the corresponding page file.
The following figure shows the current virtual memory of a Windows Server:
The figure shows SAP transaction ST06 (OS monitor) and the output of the Windows command “systeminfo”.
Windows User Mode applications like SAP work processes (WPs) use virtual memory only. The Windows Memory Manager decides which memory pages are paged out to the Windows Pagefile or kept within the RAM. SAP work processes do not use RAM memory directly.
Memory Management (MM) of the SAP Application Server ABAP (AS ABAP)
SAP MM comprises the following areas:
Extended Memory (EM)
EM is the base architecture of the AS ABAP memory management. EM is a contiguous memory area that is shared by all processes of a single application server. EM is used to store user contexts, shared buffers, ABAP programs, and table contents.
Globally shared segments (EG)
EG is an EM-based memory area. It contains user-specific data and can be accessed by all work processes like ABAP shared objects or table buffers.
Private Memory (Heap Memory)
Private memory is work process-specific and cannot be used by other work processes. In SAP MM, we distinguish between PROC memory and PRIV memory. PROC memory is used for data that is not bound to a specific user context. PRIV memory is used if the WP has used up its assigned EM memory completely. If the WP requires additional memory, this memory will be assigned as WP-exclusive PRIV memory, and the WP runs in PRIV mode.
The following two figures show the different components involved in SAP MM that consume private memory and EM:
The first figure shows work processes (WPs) consuming heap memory (PROC or PRIV memory), which belongs to one WP only.
The second figure shows the overall EM memory area comprising different memory areas like user contexts, buffers, shared objects etc. EM exists WP-wide.
The initial startup of the AS ABAP is done by starting the AS dispatcher process, a WP running in the “dispatcher” role. The AS dispatcher process creates the EM memory. The EM address space is identical among all WPs.
Profile Parameters of SAP Memory Management
SAP MM consists of a collection of different profile parameters. The following example shows the MM profile parameters involved in the user context attach and detach of the ABAP AS.
The user context contains data belonging to a user session.
As shown in the figure, MM comprises multiple different and dependent profile parameters which make it challenging to find the best suitable memory configuration.
To help you find the best MM configuration, the “zero administration memory management” was established. This MM feature ensures that the configuration of the profile parameter PHYS_MEMSIZE, all dependent MM parameters in EM, EG and ABAP runtime is automatically done.
The basis of this architecture are formulas configured for each SAP MM profile parameter, calculating the correct memory size. Keep in mind that the formulas may be subject to change in the future.
You can list the currently configured MM parameters and corresponding formulas using the following command:
sappfpar.exe check_formula pf=”\\<profile path> “
The following example shows a potential MM configuration:
Important MM Profile Parameters
In the following sections, I’ll explain the most important MM profile parameters with the corresponding, partially complex formula that calculates the memory size.
PHYS_MEMSIZE
Configures how much memory in MB or percentage (%) the AS ABAP should use. The default value is 1.0 * physical memory [RAM] of the server. PHYS_MEMSIZE is the central MM profile parameter for the “zero administration memory management”.
Note:
If the parameter PHYS_MEMSIZE is not set or is set to a value that is too large, this leads to a large EM area that is often unused because there is no application that requires such a large EM. If the Windows Server has a huge RAM size, for example 512 GB RAM, the parameter PHYS_MEMSIZE should be set to “PHYS_MEMSIZE = 25%” to guarantee that the EM is not automatically configured too big. You’ll find further details in section Recommendations and Best Practices below.
| Parameter | Description | Default Value respectively Formula |
| em/initial_size_MB | Initial size of the EM | The default value as of kernel release 740 is 0.7 * $(PHYS_MEMSIZE) and is limited to 512GB. For kernel releases 721 and 722, the default value is $(PHYS_MEMSIZE) with a limit of 256 GB |
| em/max_size_MB | Maximum size of EM | The default value is 1.5 * $(PHYS_MEMSIZE). For kernel releases 721 and 722, the limit is 256 GB, and as of kernel release 740, it is limited to 512GB |
em/global_area_MB | Size of the globally shared segments (EG) | The default formula is (min($(em/initial_size_MB) * 0.05, 32000)) |
abap/heap_area_total | Heap memory limit for AS ABAP in Bytes | The default formula is ($(PHYS_MEMSIZE) * 1024 * 1024) |
| rdisp/PG_SHM | Size of paging buffer (storing special data for the ABAP processor) in 8-KB blocks | The default formual is max(min(1000+40*max(5,floor(($(PHYS_MEMSIZE)-128) *25/128)),16384),1024) |
| abap/buffersize | Size of ABAP program buffer in KB | The default value is (min(ceil($(em/initial_size_MB)*1024*0.2/4096)*4096, ceil(sqrt($(PHYS_MEMSIZE)/1024)*1024*1024))) |
The following figure shows the dependencies of these central MM parameters:
| Parameter | Description | Default Value respectively Formula |
| em/address_space_MB | Amount of user-context memory to be reserved in a WP | The default formula is ($(em/global_area_MB) + $(abap/shared_objects_size_MB) + $(rsdb/tbi_buffer_area_MB) + ceil((($(catalog/cache_entries) * $(catalog/cache_average_entry_size)) + $(catalog/cache_empty_entries) * 300 ) /(1024*1024)) + 2 * ( max($(ztta/roll_extension_dia), $(ztta/roll_extension_nondia)) /(1024*1024))) |
| abap/programs | Directory size of ABAP program buffers in no. of entries | The default formula is $(abap/buffersize)/4) |
| abap/heap_area_dia | Heap memory limit per dialog work process in Bytes | The default value is 2000000000 (=2GB) |
| abap/heap_area_nondia | Heap memory limit per non-dialog work process (batch processes) in Bytes | The default value is 0. It depends on the available virtual memory of the server and of the parameter “abap/heap_area_total” |
| abap/shared_objects_size_MB | Memory size of ABAP shared objects | The default formular is (min(20000, $(em/initial_size_MB)*0.02)) |
| ztta/roll_extension | Value for EM per user context in Bytes | The default value is 2000000000 (=2GB) |
Changes in MM as of ABAP AS Kernel Release 7.4x
As shown before, when an attach and detach of a user context are done, the data is copied in AS ABAP kernel releases prior to 7.4x from the MM memory area named “roll area” to a corresponding roll file resource (this is not a file in the Windows server file system). The roll area is a memory area in MM that belongs to a work process. It is located in the heap memory of the WP.
As of AS ABAP kernel release 7.4x, the roll area was replaced by EM. Additional ABAP table buffers are stored in EG memory.
With these performance improvements, the size of the user contexts is smaller, but the available EM size is reduced.
The following figure shows the different EM sizes (kernel release-dependent):
As of kernel version 7.4x, the former MM roll memory (kernel versions before 7.4x) and table buffer are stored in the EM memory. For more information, see SAP Notes 2085980 and 88416.
Recommendations and Best Practices
Central MM parameter PHYS_MEMSIZE
The RAM of Windows Server hosts (physical or virtual machines) has grown continuously in recent years. If parameter PHYS_MEMSIZE is not set or set to a value which is too large for configurations of this kind, this leads to a large EM area that is sometimes unused because there is no application that requires such a large EM.
Use transaction ST02 (“Tune summary”) to check whether the EM can be reduced. Using this transaction, you can identify the highest memory usage of the EM in the past, just follow the path ST02/Detailed Analysis Menu/SAP memory/History in the transaction.
Example Scenarios
Example 1:
Let’s assume the RAM of a Windows Server host is 300 GB.
The standard value of PHYS_MEMSIZE is 300 GB, which generates an initial EM memory size of 210 GB (parameter em/initial_size_MB with the formula $(PHYS_MEMSIZE) * 0.7; see table above).
A check of the highest memory usage of 33 GB of the EM in the past (using transaction ST02) shows that a large part (> 170 GB) of the EM is not used. Nevertheless, the EM is reserved as virtual memory within the memory management of the Windows operating system.
This results in a potentially high load on Windows Server memory management in the form of unnecessarily high use of the Windows page file or insufficient heap memory, which can lead to transaction terminations.
Solution:
Perform the following configuration steps:
- Limit the parameter PHYS_MEMSIZE to 20%, which leads to an initial EM memory size of 42 GB (transaction ST02, highest memory usage of extended memory + ~25% buffer memory). This significantly reduces the amount of reserved virtual memory and increases the heap memory.
- Since EM management uses the Windows page file for its internal memory areas, check the size of the page file. Despite the large proportion of physical main memory, the page file should be configured in accordance with SAP Note 1518419 and should have at least the size of the physical main memory.
Use the Windows Server command line program "systeminfo" to check the configured virtual memory of the Windows Server with regard to the physical main memory, the page file, and the used and free virtual memory at runtime. A regular check of the highest memory usage of the EM using transaction ST02 should also be carried out.
The output of "systeminfo" run within a Windows command shell or using transaction SE38 including report RSBDCOS0 (execute OS command from SAP GUI) might look like this:
...
Total Physical Memory: 391,851 MB
Available Physical Memory: 193,364 MB
Virtual Memory: Max Size: 783,702 MB
Virtual Memory: Available: 232,236 MB
Virtual Memory: In Use: 551,466 MB
Page File Location(s): C:\pagefile.sys
D:\pagefile.sys
...
Example 2:
Now, let’s assume the physical main memory of Windows and the size of the page file are both 32 GB. A check of the highest memory usage of the EM using transaction ST02 (history) shows 30 GB. The utilization of the Windows system with the size of the EM will most likely result in a large write load on the Windows page file because the physical main memory is overloaded (Windows kernel, file system cache, third party application, or heap memory). Windows permanently writes memory pages to the page file. This is called paging.
In this case, potential configuration steps might be:
- Increase the physical main memory to 64 GB RAM and adjust the page file to at least 64 GB using SAP Note 1518419.
- Limit parameter PHYS_MEMSIZE to 80% (transaction ST02, highest memory usage of EM + ~25% buffer memory).
Example 3:
In this scenario, the size of the page file is too small.
The output of "systeminfo" looks as follows:
...
Total Physical Memory: 131,071 MB
Available Physical Memory: 106,951 MB
Virtual Memory: Max Size: 175,103 MB
Virtual Memory: Available: 28,479 MB
Virtual Memory: In Use: 146,624 MB
...
The example shows a Windows Server operating system with a main memory of 131,071 MB and a page file of ~45 GB: 175,103 MB - 131,071 MB = 44,032 MB
The page file was not configured in accordance with SAP Note 1518419 (minimum size of page file = 1x RAM).
The background for a sufficiently dimensioned page file is the technical basis of the EM, which writes/reads memory areas shared between the executed work processes to/from the page file (memory is backed by the paging file).
For more information about transactions that terminate as a result from a page file that is too small, see SAP Note 1790345.
Example from dev_w* trace file:
CreateOsShm] CreateFileMapping(6,1572864 KB) failed with Err=1455
ERROR_COMMITMENT_LIMIT: The paging file is too small for this operation to complete
The ABAP memory management of the EM attempts to write the internal memory blocks to the page file, but fails because the page file is too small.
Despite a large physical main memory, the page file should always be configured in accordance with SAP Note 1518419 (minimum size of page file = 1x RAM).
Recommendations on typical ST22 MM dumps
The following sections describe typical MM dumps reported in transaction ST22 and provide recommendations on how to change the MM configuration.
TSV_TNEW_BLOCKS_NO_ROLL_MEMORY and TSV_TNEW_NO_ROLL_MEMORY
This means that there is no memory regarding the allocation of user contexts. To analyze such an issue, clarify the EM usage in the past as described in chapter Recommendations related central MM parameter PHYS_MEMSIZE above. Additionally, refer to SAP Note 1680814-"EmAlloc failed" and other memory allocation problems.
PXA_NO_FREE_SPACE
This indicates that the ABAP program buffer is too small. Very often, the profile parameter abap/buffersize configures the ABAP program buffer too small, so you should expand it. In addition, see the following SAP Notes:
147568 - PXA_NO_FREE_SPACE
872010 - PXA: Avoid PXA_NO_FREE_SPACE dumps
SYSTEM_NO_MORE_PAGING or MEMORY_NO_MORE_PAGING
This indicates that the SAP paging memory or the SAP paging file is too small. It’s mostly because the profile parameters rdisp/ROLL_MAXFS and rdisp/ROLL_SHM are too small.
For more information, see the following SAP Notes:
133909 - Maximum value for PG_MAXFS, PG_SHM, ROLL_MAXFS, ROLL_SHM
2133412-Default calculation for rdisp/PG_MAXFS und rdisp/PG_SHM as of Kernel Release 7.41
1563748 - MEMORY_NO_MORE_PAGING dump occurs in ST22 - SAP for Me
TSV_TNEW_PAGE_ALLOC_FAILED
This means that an ABAP program cannot allocate enough memory for internal table memory. To analyze and solve this issue, check the EM usage as described in chapter Recommendations related central MM parameter PHYS_MEMSIZE above. In addition, see SAP Note 369726 - TSV_TNEW_PAGE_ALLOC_FAILED.
PXA_NO_SHARED_MEMORY
This indicates that the ABAP program buffer cannot be created with the size specified in the profile parameter abap/buffersize. Usually, it’s because the Windows Virtual Memory Manager cannot provide a coherent memory area as required by the MM. The usual error in the log files of the application server is “Error 1455: The paging file is too small for this operation to complete”. To solve this issue, configure the Windows page file in accordance with SAP Note 1518419. Additionally, see SAP Notes 4101 - PXA_NO_SHARED_MEMORY and 307976 - PXA_NO_SHARED_MEMORY.
Important SAP Notes related to AS ABAP Memory Management
In the following, you’ll find a collection of SAP Notes that help you improve your AS ABAP memory management.
4101 - PXA_NO_SHARED_MEMORY
16244 - Setting nametab buffer sizes
88416 - Zero administration memory management for the ABAP server
133909 - Maximum value for PG_MAXFS, PG_SHM, ROLL_MAXFS, ROLL_SHM
146289 - Parameter Recommendations for 64-Bit SAP Kernel
147568 - PXA_NO_FREE_SPACE
307976 - PXA_NO_SHARED_MEMORY
369726 - TSV_TNEW_PAGE_ALLOC_FAILED
872010 - PXA: Avoid PXA_NO_FREE_SPACE dumps
1416152 - High paging rate for backup on Windows Server 2003 and 2008 (R2)
1514752 - Extended Global Memory configuration Parameters
1680814 - "EmAlloc failed" and other memory allocation problems
2019744 - How to limit overall swap space consumption of the ABAP Server in NW 7.40
2085980 - New features in memory management as of Kernel Release 7.40
2133412 - Default calculation for rdisp/PG_MAXFS und rdisp/PG_SHM as of Kernel Release 7.41
2180736 - TSV_TNEW_PAGE_ALLOC_FAILED short dump
2259826 - Remove the limit on extended memory
2652181 - Value for "em/address_space_MB" is too low
2660701 - Memory disclaiming in heap
2693696 - Improved locking in ES layer
2733232 - PROC memory consumption included in StackTrace information
2835377 - MtxLock EMHYP deadlock
2915629 - High resource usage ascertained (Resource=EG MEMORY, Limit=90.000%, Curr.=94.215%)
2959509 - Possible deadlock for out-of-memory error in EG
2969678 - Replace the locking from semaphore to mutex while registering mmx handles in EG
3002421 - Possible deadlock for out-of-memory error in EG II
3024505 - Error in MmxCheckOpenHandles
3098665 - SAP instance does not start; out of memory in EG
3108158 - ATC checks of SAP Readiness Check for SAP S/4HANA breaking
