Skip to end of metadata
Go to start of metadata

Purpose

Help you to understand the shared memory pools 10 and 40 concept as of kernel 740 and how they are sized in the ABAP application server environment. 

Overview

This page contains information about the shared memory pools 10 and 40 and the new mechanism to calculate their size as of kernel 740.

Shared Memory Pools Sizing before SAP Kernel 740

Before the Kernel 740, depending on the size of the buffers inside of the shared memory pools 10 and 40, it was recommended to increase the size of the buffer so the content could fit inside it and the system could start successfully and work without issues. This sizing was made by using the parameters ipc/shm_psize_10 and ipc/shm_psize_40 as per the SAP documentation Adjusting Pool Sizes. Also, the pool sizes could automatically be increased in the start up moment, writting entries informing this in the dispatcher trace.

Shared Memory Pools Sizing as of SAP Kernel 740

As of the Kernel 740 many memory managent concepts have changed. The SAP Note 2085980 explains many of these changes. For example the abolition of the classic Roll Memory which is now a part of the Extended Memory and the availability of Zero Administration Memory Management to UNIX platforms between others.

As you can see in the below image, many memory and buffer parameter are now by default based on formulas which are directly and indirectly dependent on the value of the PHYS_MEMZINE parameter, which has the value of the total available memory in the server. 

 

Some of the above buffer parameters like rsdb/ntab/ftabsize, rsdb/ntab/irbdsize and rsdb/ntab/sntabsize are contained by default inside of a shared memory pool (in this case the pool 40) and as you can see their values are also by default defined based on a formula which indirectly related to PHYS_MEMSIZE. Based on this fact, it makes no sense to have statical values for the size of the shared memory pool buffers defined in the profiles and also default statical values in case the parameters are not defined, since it could easily cause a situation where the pool is too small for the size of the buffers contained on it and as consequence the system would not be able to start.

 

 

In order to prevent start up problems and authomatize the sizing of the shared memory pools, if the ipc/shm_psize_10 and ipc/shm_psize_40 are not defined in the profiles, the kernel will automatically calculate the size of the pools 10 and 40 in the moment of the start up based on the size of the buffers contained on them. This explains the fact that documentation in RZ11 for the parameters ipc/shm_psize_10 and ipc/shm_psize_40 recommends the parameters not to be changed and specified as of this release.

ipc/shm_psize_40:
"Size of SHM pool 40. This parameter should no longer be changed as of Release 7.40 SP2."

ipc/shm_psize_10 
"Size of SHM Pool 10. This parameter should not be used from release 7.40 upwards."

Note:

                1.  As of 74x  kernel onward, the Kernel will not follow the manual configuration of shared pools, it automatically calculate the shared memory.

                2.  You  can ignore the error entry from the sappfpar regarding ipc/shm_psize_10 or ipc/shm_psize_40  . (For example ERROR: Size of shared memory pool 40 too small )


Memory Administration and Sizing of the Pools

The shared memory pools in all the kernel versions are normal shared memories, therefore there is no size restriction for them. However, the administration inside the pools handle the different memory keys still with a 32bit model (since it has to be compatible with 32bit executables which will have to attach to pools from outside). This characteristic leads to problems whenever the shared memory pool sizes grows biggrer than 2GB, since some of the shared memory keys inside the pool will share the same memory spaces, causing a system crash.

In case a shared memory pool needs more than 2GB of space since some of the areas contained inside it are occupying a huge space, These areas must be located outside of any memory pool as described in the SAP Note 1137734. This will make sure information can be written in the segment without corrupting the next memory area and therefore the system can still work correctly.

Related Content

Related Documents

Adjusting Pool Sizes

Related SAP Notes/KBAs

SAP Note 2085980: New features in memory management as of Kernel Release 7.40
SAP Note 1998242: Changes about Roll area from SAP_BASIS 7.40 SP2
SAP Note 88416: Zero administration memory management for the ABAP server 
SAP Note 1137734: Assignment of memory areas, shared memories, and pools