How to analyze Memory problems for SAP Systems on 32-Bit Windows platforms
This blog doesn´t intend to explain in detail the SAP memory management but only to address some typical memory problems in windows 32-bit platforms. Memory problems related to application issues or to big criteria selection running transactions or programs are not covered here.
On a 32-bit platform every Windows process can address up to 4 GB of virtual memory in its own address space even if there is much more physical memory available.
This memory consists of 2 parts: the user part (where the user program can allocate the memory) and the kernel part.
Under normal circumstances, both parts are 2 GB, although using the option /3GB in file boot.ini (note 110172 ) only 1 GB is left to the operating system and 3 GB for user process. Sometimes it causes problems if the operating system needs more than that (note 990538), so you can use also option /USERVA for tunning between 2 GB and 3 GB the address space the user process can use. For example:
/USERVA=2700 in file boot.ini:
- 2.7GB for user program (SAP)
- 1.3GB for Kernel processes (OS)
This limitation on an ABAP application server can lead for example to short dumps of type ‘TSV_TNEW_PAGE_ALLOC_FAILED’ or STORAGE_PARAMETERS_WRONG_SET’ when you run a program or transaction in a SAP work process.
Typically these short dumps mean that the Operating system can not provide more memory when it is requested by the work process.
The main part of this address space used by the work process (2GB – 3 GB) is filled as follow :
- – SAP Buffers: contain global objects for all users and work processes, such as programs, and buffered table content. Allocated at System Startup.
- – Extended memory contains objects associated with individual users and their open transactions, such as variables, lists, and internal tables
- – Heap memory: Contains the same type of data as the extended memory and is used when extended memory is full. It is allocated (after PRIV Mode) and released on demand (after reaching abap/heap_limit)
This mean that when a “running work process” use all the extended memory and enter in private mode using heap memory it will provoke a short dump if the sum of the consumed memory : “SAP Buffers” + “Extended Memory” + “Heap memory” reach the limit of of the addressable user space ( 2 GB – 3 GB)
The memory parameters for sizing extended and heap memory are recommended to be set as explained at note 88416 and you can check it quickly at transaction ST02 -> current parameters:
The size of extended memory is set with parameter em/address_space_MB to 512 MB (0.5 GB) and the limit of available heap memory is set with parameters abap/heap_area_nondia (dia) to 2 GB.
So to check if it is possible to get more memory available to run the work process , it should be checked the settings of the memory buffers. In transaction ST02 -> detail analysis menu -> storage you can see all the allocated memory for SAP buffers
In this case system has about 900 MB (0.9 GB) used for SAP Buffers.
It means that for 2 GB of available user space less than 1.1 GB is left for running the work process using extended and heap memory (2.1 GB with option /3GB enabled). The other 0.9 GB is used to allocate the SAP buffers.
You can check in detail the size of the different buffers pushing in this screen the button “shared memory detail” :
In this example you can see that the biggest part of the consumed memory is due to:
– ABAP program buffer (500 MB)
- – Shared roll buffer (60 MB)
You can check the parameters related to these buffers in transaction ST02 -> current parameters:
- – rdisp/ROLL_SHM
It means that the more the SAP buffers size is incremented the less memory is available to run a program or transaction in the SAP work process.
Even in the case you increment too much the SAP buffers size , it could happen that the SAP system will not be able to start.
For example if you set abap/buffersize to 1.000.000 (1 GB) , then, around 1/2 to 1/3 of the available user space will be reserved only for the ABAP program buffer and may be there is not enough space to run the work process or at less to run a complex program or transaction.
To summarize, the following points should be check from memory point of view:
– Memory parameters are set according to note 88416 (Zero Memory Management)
- – Option /3GB is enabled to get more memory available for the user space. See note 110172.
- – Check the size of SAP buffers and and reduce if possible. Some of the most important are :
- PXA: abap/buffersize
- ROLL: rdisp/ROLL_SHM
- PAGE: rdisp/PG_SHM
The criteria for reducing some SAP buffers should be a hit ratio more than 99% for any of them in transaction ST02 -> Detail analysis -> History to avoid performance problems.