Skip to end of metadata
Go to start of metadata


How to check situations where the memory is not released and/or we observe a high memory allocation.


The user contexts are stored in the extended memory first, and if more memory is needed, in the heap memory, which is the local memory of the work process. The extended memory is where the large part of the user context is allocated.

The Extended Memory consists of two layers: the EM, used by ABAP, and the ES, which is operating system-dependent. The ES is the layer which maps operating system blocks together to an EM block. In transaction SM04 you see the memory which was allocated by ABAP.

When a user context releases local process memory, it remains occupied from the operating system point of view. It only becomes available for other processes when the process itself is ended. That’s why work processes are restarted. This behavior is controlled by parameter abap/heaplimit.


Checks depending on the operative system


The first thing would be to identify the process consuming a lot of memory at OS level.

In WINDOWS you can use the task manager for this purpose.

In UNIX you can run the following script at OS level. It monitors the 10 largest processes every 30 seconds:

while (1)
      date >> pssize.log
      ps alwg |  sort -n +10 | tail -10 >> pssize.log

      sleep 30


As of release 740 SP08, the memory leak analysis can be done easier using RSMEMORY, thanks to the new memory class "PROC-Memory". The recommendations given in point 3 of the following SAP note is helpful: 2085980 - New features in memory management as of Kernel Release 7.40


AIX. To analyze a high memory consumption, you can execute the command “svmon -P <pid>“, explained in the following SAP note 1971698 - High Memory Consumption on AIX

The analysis sorted by memory can be obtained executing “usagesvmon -U <user_id>”.

SOLARIS. You could run "prstat -s rss -can 10 5 40". In the column SIZE will show the virtual memory and the column RSS what the process actual use.


General checks

Other checks that should be done:

  • SM04/SM66 -> to check if the session of an user and its memory allocation remains, even when rdisp/plugin_auto_logout seconds have passed. Please note that in a SM66 screencapture the user allocating a lot of memory won’t be shown if he isn't active at the specific timestamp when you collect the screenshot.
  • STAD to check what the user is executing and in which work process. This will help to look for possible error entries in the work processes log files (dev_w*)
  • ST02 -> Detailed Analysis Menu -> SAP Memory -> Mode list, to see the extended memory allocation for users. The list can’t be sorted.
  • ST03N -> Memory use statistics
  • Check the SAP regression note for your kernel patch level to discard a possible kernel bug or memory leak at OS level. You can find the corresponding note using the keyword KRNLxxxPLyyy in the SAP note search.
  • Check value of the following parameters:
    • abap/heaplimit -> perhaps it's set too large
    • rdisp/plugin_auto_logout -> it may be set to 0, meaning that the resources for the HTTP(s) sessions are never released
    • rdisp/gui_auto_logout -> the same but for the GUI sessions
    • rdisp/wp_auto_restart
  • If we are working with web services, it is also important to check if there is any other timeout defined in SICF for that webdynpro.
  • Check the memory parameters are correctly set according to the platform / kernel release the system is running
  • Check if there was some memory shortdumps in transaction ST22.

Related Content

Related Documents

Types of memory

ABAP Heap Limit

CST Wiki Memory Management


Related SAP Notes/KBAs

SAP Note 158346: Periodic restart of work processes

SAP Note 2065315: Memory leak handling

SAP Note 2019744:- How to limit overall swap space consumption of the ABAP Server in NW 7.40

SAP Note 2065315: Memory leak handling

SAP note 1971698: High Memory Consumption on AIX

SAP Note 2085980: New features in memory management as of Kernel Release 7.40


  • No labels