Release of SAP Memory for the Operating System 

Use

When memory that was allocated for SAP components in the SAP Extended Memory (EM) is released, for the operating system (OS), the memory remains in the status “occupied”. As the SAP system sees it, the operating system handles released extended memory exactly the same as it handles memory currently occupied by SAP components. If a memory bottleneck occurs the operating system writes the memory pages to the paging file (swap space in the operating system). Before the memory pages can be used again by SAP components, the operating system has to read them back from the paging file.

You can use profile parameters to set the threshold at which memory is released for the operating system.

Integration

The disadvantage of the process described above becomes apparent if a memory bottleneck occurs, as the operating system does not know that the content of released pages is obsolete, and has to save the content to the paging file, before the physical pages can be used for other purposes. When the pages are reused, the operating system also has to read obsolete contents from the paging file as well as provide empty memory pages.

Prerequisites

This function is available in a kernel patch for SAP kernel 4.6D, 6.20 and 6.40. The profile parameters are normally imported into the system from support packages (transaction RZ11).  However, you can still use these parameters, even if you have not installed the relevant support package.

The procedure described here does not work, if the ES/TABLE = SHM_SEGS  parameter is set. In this case memory is already released for the operating system.

Features

You can control the amount of memory released for the operating system in relation to how busy the extended memory is, and thereby minimize the problems associated with a fully occupied extended memory.

Memory above an adjustable threshold in the extended memory is always released for the operating system.  As soon as this threshold is exceeded, memory below this threshold can also be released for the operating system for a specified time period.

When EM blocks are released, a definable size of the upper section of the EM block can also be released for the operating system.

The default procedure when memory is released is the same as the procedure described earlier, that is, no memory is released for the operating system.

The release of memory for the operating system can be activated by the following parameters:

·        es/disclaim_threshold_MB (default: 0, ineffective) specifies the threshold above which memory is released for the operating system)

·        es/disclaim_coasting_time_alloc (default: 0, inactive)

·        es/disclaim_coasting_time_free  (default: 0, inactive) specifies the coasting time in seconds, how long after the threshold has been exceeded memory below the threshold is also freed up for allocation to or release from the operating system.

·        es/blockdisclaimsize_KB  (default: 0, inactive) This parameter specifies in kilobytes the size of the upper part of an EM block that is also released for the operating system. It combines the benefit of smaller EM blocks (em/blocksize_KB) with regard to the main memory requirement, with the benefit of larger EM blocks with regard to performance.

·        es/freelist_compactor (default: 1) should not be 0, so that the process described above can be fully effective.

Activities

Import the required kernel patch. The patch text is ‘CST Patch Collection 15 2004’.

Set the profile parameters as you require.

Example

em/blocksize_KB                 = 4096  (4MB, default for 64 bit)

es/blockdisclaimsize_KB         = 2048   (2MB, 1/2 of em/blocksize_KB)

es/disclaim_threshold_MB        = 12000  (OS memory release for >12GB)

es/disclaim_coasting_time_alloc = 300  (coasting time for OS release when allocating memory)

es/disclaim_coasting_time_alloc = 60  (coasting time for OS release when freeing up memory)