Skip to Content

How to analyze Memory problems for SAP Systems on 32-Bit Windows platforms

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:


  • – abap/buffersize
  • – 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 :


  1. PXA:   abap/buffersize
  2. ROLL: rdisp/ROLL_SHM
  3. 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.

You must be Logged on to comment or reply to a post.
  • Hi Manuel,

    I like the way your blog is produced.
    The formatting is nice, the pictures are well done and the content surely is correct.

    But… 32-Bit memory issue analysis?
    Seriously? Today?

    Honestly, whenever I come across an issue in this area, I won’t put too much thought into it anymore.
    64-Bit is available for only a few bucks nowadays so trying to squeeze a full-blown SAP installation into the memory limits is just a waste of time.

    Besides – 32-bit versions are not done for newer releases anymore. And rightfully so!

    Anyhow: nice blogging and keep on!

    • Hi Lars,

      Thank you for your comments.

      You are right, it is recommended to use a 64-bit platform in version 700 and newer.

      But currently  there are a great deal of SAP installations running on windows 32 bit platforms, even  upgraded to version 700.
      Unfortunatelly nowadays it  often leads to  memory problems that could be avoided with a 64 bit platform.