/SDF/MON – SAP memory review and analysis

SAP transaction /SDF/MON can be used to collect SAP memory usage snap-shot to show how much SAP memory a SAP user process/program/job is used and how much SAP memory is used by all SAP processes in the instance at any specific moment according to a frequency you specify. When a process/transaction/program/job is finished, you can just review memory snapshots at your own pace to know the its’ SAP memory usage pattern instead of sitting in front of your PC and keeping refreshing your SM50 details screen. This is a great feature I love very much whenever I need to analyze memory usage for a business program or a SAP system in SAP project or SAP production operation support. In this post, I would show

  • How to use SAP /SDF/MON to verify/monitor memory usage pattern of a single SAP job/program
  • How to use SAP /SDF/MON to verify/review memory peak and non-peak usage in a SAP system

You can click here if you want to know how to run SAP transaction /SDF/MON to collect system performance snap-shots.

1. How to use SAP /SDF/MON to verify/monitor memory usage of a single job

1.1 Background of SAP memory issue

In this case, business is complaining that SAP job was cancelled. Checking ST22 core-dump, it is found that job was cancelled due to memory contention. However ST22 core-dump shows that heap memory occupied by the job at the time of job termination is far below what has been allowed by the SAP system. What happened? Is there a system memory contention in heap area or the job itself is using too much memory over the SAP memory quotas. I turned to SDF/MON memory snapshots to look for the answer.

1.2 Use SAP /SDF/MON to review memory usage pattern

My analysis path is: get when(job runtime window), who(SAP job step USER-ID) where ( executing server ) information via SAP transaction SM37 using job name, run /SDF/MON to filter display based on SM37 information so only relevant information is displayed for analysis. Then I displayed the last snap-shot taken by SAP transaction /SDF/MON before the job was cancelled to see how much memory was used by the job.

1.2.1 Use SAP SM37 to find out who, when and where information for memory analysis

Based on job name related to my case, I got following information via SAP job monitor transaction SM37:

Figure 1 SAP SM37 job info

From above screen, I found that SAP user (*684), run-time window ( 18:17:55 -18:50:56) on Nov 15 2012 in SAP server *01. This is masked to protect private information.

1.2.2 Check ST22 to find out why a SAP job is terminated fallout – No roll memory

I run ST22 to get system core-dump information to know why the job was cancelled. You can limit your st22 report using SAP userID and date etc. Following is part of ST22 core-dump related to above jobs. It indicated that the job was terminated due to memory error ” TSV_TNEW_BLOCKS_NO_ROLL_MEORY”.

Figure 2 – ST22 core-dump

Above screen shows that memory usage is under 90 MB at time of termination. In ST02, it shows that system heap memory has not reach the limit and allowed memory for individual job is over 2G bytes. You can click run SAP transaction ST02 – “SAP memory monitor” to know how to run ST02 to get SAP memory quotas for individual job/program.

1.2.3 Use SAP /SDF/MON to review memory snapshots

Run SAP /SDF/MON transaction and display the snap-shot for the day when job was aborted. Then using following filter

Figure 3 – /SDF/MON snap-shots

Where (which server) and when (which specific moment) comes down to a row/entry where you place the cursor in above /SDF/MON display screen. After you select the entry, you can enter F5 key or click memory mode display icon , SAP /SDF/MON would show memory utilization at user/transaction level.

Since our job is aborted at 18:40:50, so I chosen the snap entry at 18:39:00 – that is the snap-shot immediately before the job termination:

Above screen shows that user *684 was using about 3.5G memory not 90M showed in SAP ST22 transaction. And heap memory used is 3.5G as well. From SAP ST02 transaction, I can know our system configuration on how much memory a job can use up to. So the job was requesting more memory than what system allows for a single job. When that happens, the SAP system terminates the job/program. To fix the issue, we can either reduce job/program volume or tune corresponding program from design and code.

You can use SAP /SDF/MON snap-shots to understand a SAP Job/program memory usage pattern as well by reviewing a job/program memory usage at different moment during the time window when the job is running.

Following are some of sample screens which shows that memory used by the job is increasing with runtime increasing:

 

 

2 How to use /SDF/MON to analyze system/server level SAP memory consumption

2.1 Schedule SAP /SDF/MON to collect performance snap-shot

For SAP system memory utilization analysis, following choices should be selected when SAP /SDF/MON transaction is scheduled:

  • SAP work process – this would tell you what business process /job is running in the system.
  • Extended and heap memory – This would tell you overview of memory usage at instance/server level.
  • Memory per modes – this would tell you memory usage at each user level and/or transaction level.

As to how often you should collect the snap-shot, I think collecting snap-shot at a frequency of every 1 minute to 10 minutes should be good enough in most cases. Collecting snap-shot can put additional load on the system and additional disc space. The actual frequency would dependant on your system.

2.2 Analyze performance snap-shot

The analysis of /SDF/MON SAP memory usage snapshot is to focus on two areas:

  • System level SAP memory contention point/trend.
  • Top users of SAP memory which contributes the memory contention.

2.2.1 Analyze system memory usage

Before we analyze memory, we need to understand important memory columns in following SAP /SDF/MON monitoring data screen.

Column

Explanation

Comment

Free memory in KB

Free memory at server level.

This value is the free physical memory reported by ST06 – operating system monitor

Allocated Extended memory in MB

Used extended memory at instance/server level.

This value is the same data under field “CurUse(KB)” in SAP ST02 – Memory monitor for “Extended memory” row.

Heap Memory in KB

Used heap memory at instance level.

See above but for “Heap memory” row.

Page SHM

Used Paged memory at instance level.

See above but for “Page area” row.

Roll SHM

Used Roll memory at instance level.

See above but for “Roll area” row.

 

: Using this icon, you can see memory usage of each user/transaction in each snap-shot.

You also need to get some understanding on your system capacity via SAP transaction ST06 and SAP memory setting via SAP transaction ST02.

With collected SAP /SDF/MON memory snap-shots and understanding of the system, it is now easy to analyze SAP memory usage to identify potential memory contention and top memory user/transaction

  • Sort SAP /SDF/MON monitoring data based on Extended Memory column descending – top extended memory usage is on the top of the display.
  • Sort SAP /SDF/MON monitoring data based on “Heap memory” column descending – top heap memory usage is on the top of the display.
  • Drill down into memory per modes, you can identify sap users/transactions which are using most of memory – this can lead to review on the job-variant/program review to reduce memory consumption.

3 further information

Now you know how to use SAP /SDF/MON to analyze individual SAP job/program’s SAP memory utilization and server/system’s SAP memory utilization. SAP program /SDF/MON can be used to do performance analysis in many other areas. One of critical performance area is SAP system load/CPU utilization analysis or SAP system load balance analysis, I have a post on how to use /SDF/MON to do SAP load balance analysis.

When you need to monitor a single job for memory utilization, it would be better to assign an exclusive SAP user-id to a background job since SAP /SDF/MON “memory snap-shot has no information in the “memory per modes” snap-shot. So you would know for sure that all memory occurred under that user id is for that job when the SAP user ID is exclusively used for a job.

There are other SAP tools which can report memory usage like STAD, ST03N, SM04 and ST22 –they cannot report the trend or pattern of memory usage over job runtime and SAP memory reported by those tools sometimes does not reflect true SAP memory peak usage as it shows in this case. You can get memory information for a single process via SAP transaction SM50 sap work process monitor, ST02 SAP buffer memory monitor and SM04 SAP logon users monitor but you need to sit in front of your computer to keep refreshing your screen. So SAP tool /SDF/MON stands out as a great and convenient tool to analyze system level memory usage/trend and monitor individual SAP job/program/process memory consumption.

Again, SAP /SDF/MON is one of great tools which can be used to monitor almost all critical areas of SAP system performance.

 

 

 

 

 

 

3 thoughts on “/SDF/MON – SAP memory review and analysis”

  1. Good post. But it will be interesting to know about parameters like
    EM global and EM attached )
    And I should also mention that this tool is not relevant for AIX monitoring ( I didnt find this in the post)

    1. Many thanks for your input. I have not delt with any issue with EM global adn EM attached personally based on the my SAP environment. Thanks for pointing it out that this tool is not applicable for AIX monitoring. I was asuming that this is a generic SAP tool which only depends on SAP version not OS.
      EM attached is not separate SAP memory area which can be defined by a SAP parameter. Yes EM global can be defined by SAP parameter EM/global_area_MB and it is part of SAP extended memory. EM attached is reflecting extended memory which are consumed by active SAP workprocesses. If you would like to contribute a post to share your uniqe experience with EM global and Em attached, you are very welcomed!

    2. Many thanks for your input. I have not delt with any issue with EM global adn EM attached personally based on the my SAP environment. Thanks for pointing it out that this tool is not applicable for AIX monitoring. I was asuming that this is a generic SAP tool which only depends on SAP version not OS.
      EM attached is not separate SAP memory area which can be defined by a SAP parameter. Yes EM global can be defined by SAP parameter EM/global_area_MB and it is part of SAP extended memory. EM attached is reflecting extended memory which are consumed by active SAP workprocesses. If you would like to contribute a post to share your uniqe experience with EM global and Em attached as well as AIX, you are very welcomed!

Leave a Reply