Tag Archives: How to use SAP ST06 for CPU/Memory load analysis;SAP ST06 performance analysis; SAP ST06 CPU load analysis; SAP ST06 Memory load analysis; SAP ST06 load balance; SAP ST06; SAP ST06 and SM50 process li

How to use SAP transaction ST06 for SAP performance analysis

In my previous post, I have covered how to run ST06, navigate through important ST06 screens and understand those screens. In this post, I would talk about how to use SAP transaction ST06 for performance analysis:

  1. Use SAP ST06 to do CPU workload analysis
  2. Use SAP ST06 to do SAP system memory load analysis
  3. Other analysis

I mainly focus on CPU and Memory analysis which are often showed up as a concern to application/system performance. SAP ST06 itself cannot provide all data needed for CPU load and memory performance analysis. SAP ST06 can be used to find out when and where there is a performance concern related to CPU and memory etc for further analysis. Working in conjunction with other performance tools like SAP workload monitor – ST03/ST03N, database load monitor- ST04, SAP transaction statistics tool – STAD and SAP snapshots collector -/SDF/MON etc, you can identify SAP work processes , jobs/programs, users who contributed to CPU/Memory performance issue, then solutions/options can be reviewed and worked on subsequently.

1 Use SAP ST06 to do CPU workload analysis

CPU workload analysis is to make sure that CPU workload is not exceeding recommended utilization 80% and maintaining CPU workload balance by analyzing peak load period and load distribution pattern.

1.1 Review CPU load to make sure CPU utilization under the recommended threshold

One of important goals for CPU workload analysis is to make sure that CPU utilization is not over general recommendation – Sum of User and Sys CPU utilization should not over 80% on hourly basis. For application server, system utilization portion of CPU should not be over 10% and for data base server, it should not be over 20%. It is more critical to maintain at least 20% CPU idle rate for database server since database server is a central instance and all SAP transactions/programs need to access database server one way or another.

You can run ST06 and refresh the main screen to see whether CPU is over utilized now. You can use hourly CPU utilization history for the past 24 hours or daily average in the past 30 days provided by SAP ST06 to see whether CPU has been over utilized in the past. If there are situations that those thresholds are exceeded, you need to look into the details on who (jobs, processes or users) are contributing most to the over utilization so you can review the situation and identify the solution.

Then you might ask how to identify top jobs, processes or users who is consuming a lot of CPU power. Unfortunately, SAP ST06 itself cannot provide SAP jobs or processes names. You need to use different SAP or non SAP tools to complete the performance analysis dependant on whether you are reviewing a current CPU load concern or past CPU load concern. Since we are dealing with SAP system performance and the CPU overutilization is mostly related to processes from SAP in most cases, this post would cover details how to identify top SAP jobs, processes or users. There are cases when non SAP processes are making significant contribution to CPU overutilization, I would briefly mention this.

1.1.1 How to identify TOP CPU SAP user, processes, programs/jobs related to current CPU load issue

First, you need to refresh ST06 “Top CPU” process screens to know which ST06 process is a top CPU process. Following is a part of ST06 “Top CPU processes” screen:

Figure 1 ST06 TOP CPU processes

If a process is continuously showed at top of above screen during the observation period, then it is an expensive process. If it is related SAP work process or a SAP database session/process. You can find corresponding sap user, sap work process or database session, SAP job/program name via following method.

For a process in ST06 Top CPU processes screen which is related to a SAP work process, you can use following way to identify related SAP user, program or jobs-

  • Get the “Process ID” from ST06 Top CPU processes screen.
  • Run SAP work process monitor SM50 and locate SAP work process based on “Process id”. From SAP SM50 screen, you can know the SAP process type, program name and SAP userID.
  • For SAP background process, you can find corresponding SM37 job name: Run SE16 against SAP table TBTCO, put “process-id” into field TBTCO-WPPROCID, execute it, you would get SM37 job name. There are other ways to get background job name based on “process ID”.

For a process in ST06 Top CPU processes screen which is related to a SAP database process, you can get the corresponding database process and further the SAP work process if applied:

  • Get the “Process ID” from ST06 Top CPU processes screen.
  • Run SAP ST04 database process/session monitor. “Process ID” in step 1 is actually “Operating System PID” in ST04 session monitor. So you can identify the corresponding database session to know the SQL statement which is causing the load on the database server – from there, you can review the SQL statement to identify any possible improvement opportunity. Please refer to my post on how to tune SQL.
  • Most of database processes are result of running SAP application jobs or programs. You can identify the corresponding job or programs via client ID in ST04 session monitor screen. Client ID is actually mapped to SAP50/SM66 work process ID.
  • You can identify corresponding SAP job if it is a background process (see above).

If a process in ST06 Top CPU processes screen is a non-SAP process and you do not have access to operating system shell, you need to talk with your system-level administrator to find out operating system level program/script/job name.

ST06 process name like DW.* is related to SAP work process in SM50. ST06 process name like “ORACLE*” is related to a database session/process in ST04. This has been covered in my previous post how to run ST06, navigate through important ST06 screens and understand those screens.

1.1.1 How to identify TOP CPU SAP user, processes, program/jobs related to past CPU load

For past CPU overload, you need to use SAP transaction ST03/ST03N – SAP system workload monitor to analyze the workload for the specific period to identify top offenders. SAP transaction ST03/ST03N is an important performance tool. You can use ST06 data as an input for ST03/ST03N analysis. If /SDF/MON is scheduled in the system, you can use /SDF/MON system performance snapshots to do further analysis.

1.2 Review CPU load to achieve better load balance

Another goal of CPU workload analysis is to achieve CPU load balance including vertical and horizontal balance. Vertical balance is to make sure that the same SAP server has proper load balance over time period such as a day or a week. The objective of vertical CPU load review is to spread CPU load out over time so a server CPU power can be used equally in different time period as much as possible. The objective of horizontal CPU load review is to spread CPU load among all servers/instances of a SAP system so each server of a SAP system has equal utilization at any specific moment whenever possible. In reality, it is impossible to achieve absolute vertical or horizontal CPU utilization balance due to various reasons – business office hours and non business office hours, business pattern(seasonal ), different level of resource consumption by different programs/jobs and different level of resource consumption by the same program due to volume difference etc.

SAP ST06 can display hourly CPU utilization for past 24 hours. It can display daily average CPU utilization for a single server and across systems for the past 30 days. This information is an input for load balance analysis. SAP ST06 cannot tell you which users and processes are creating those loads. You need to work with SAP workload monitor ST03/ST03N to find further details.

Load balance issue is normally caused by many concurrent running SAP work process as a result of parallel solution, immediate processed EDI/ALE interface in my experience and incoming RFC calls etc. SAP CPU workload balance analysis should look into those areas first. It is really rare that culprit is singe thread of SAP work process.

1.3 Understanding CPU load and application/system performance

CPU load is an important factor for application/system performance. But there is no simple equation to say: high CPU load = bad performance, low CPU load = good performance; High CPU load = bad user experience, Low CPU load = good user experience. You can refer to my previous post to understand other factors which might influence a program performance. However I would assume here that CPU is only factor which influence performance to make discussion simple.

Even hourly average CPU utilization is under 80%, this does not mean all business transactions executed in that hour would have normal performance. Whether there is a performance impact, this really depends on CPU load distribution in that hour and how sensitive a business transaction is to runtime. For example, if CPU utilization for 1st half hour is 90% and 2nd half hour utilization is 10%, then average CPU utilization is 50% for that hour well below the recommended utilization, however performance of a business transaction which is running in the 1st half hour would be very likely impacted. This would also depends on normal utilization – If normal utilization is 50%, then CPU utilization jumps to 80%, an application or transaction performance might be impacted. If a job/program normally runs for several days, then single hour CPU over utilization on runtime of such job or program can be ignored. In another way, when we evaluate CPU impact on a long running transaction/job runtime, we need to check CPU load history instead of current CPU load.

Also if a SAP system has separate database server and application server, one server has overloaded but another server is ok.. the performance impact on a transaction might depends on where the transaction spends most time. If 99% of time is spent on database server and database server is not over loaded , CPU contention on an application server is very likely have no impact on the performance of transaction where it is executed on application server. So on.

Even performance of all business transactions in the SAP system are impacted from technical analysis point view. This might be different from what business users feel. Since each business transaction and process has an acceptable runtime range – that is SAP users’ expectation as well. Business users would only feel the performance impact if business transaction or performance has a notable deviation from its’ normal runtime range. For example, a background job has a run time range of 1 – 2 hours based on volume, business might not feel difference if what should be finished in 1 hour normally for small volume takes 1 and half hour due to CPU overutilization. However, business would feel the performance issue if big volume happens to kick in while there is a CPU overutilization in this case.

Technically, CPU load would impact a program/job performance if a business job needs CPU but have to be put to wait due to CPU contention. When a job/program spends a lot of time waiting for CPU, its’ performance is impacted. SAP transaction STAD would show statistical data of job/program runtime –which break job runtime down to further components. Analysis of those components can help you to understand the impact of CPU contention. For example, in server with 4 processors running only 4 jobs and each of 4 jobs is purely doing calculation w/o disc for hours, You should see CPU 100% utilization but each of 4 jobs spends no time in waiting for CPU.

Under current SAP technology, we normally do not need to worry about individual CPU/processor utilization showed in Snapshot – CPU screen (Not TOP CPU screen which shows a list of work processes). However, this could be a concern if one or more of server CPUs are reserved for specific purpose/application.

1.4 Other CPU workload analysis tools

There are other tools for CPU load analysis. I have mentioned SAP workload monitor – SAP transaction ST03/ST03N in previous section. It can be used to do workload analysis as well. You can use ST06 to identify peak load period and use SAP workload monitor ST03/ST03N for further analysis. SAP database load monitor ST04 can be used to monitor SQL operation load on database server. I would cover SAP workload monitor ST03/ST03N and database load monitor ST04 in the future.

My favorite tool for load monitor analysis is SAP performance snapshot program /SDF/MON. /SDF/MON is not good for current CPU contention but it can be used to collect CPU load snap-shots for historical utilization analysis. ST ST06 is good for current CPU load analysis but depends on other tools to find process, sap job, user and program information. So you can ST06 to know when there is a CPU contention, then use SAP /SDF/MON transaction to collect snapshot for that particular period for details analysis. You can refer to my post SAP /SDF/MON workload analysis for details on how to use SAP transaction /SDF/MON in load analysis.

1.5 Process relation among SAP ST06, SM50/SM66 and ST04

This section would tell you the linkage among ST06 TOP CPU process, SM50 SAP work processes and ST04 database process/sessions via examples. Exception where a process exists in one tool but not in another tool due to SAP job cancellation etc is not discussed here.

1.5.1 How is a ST06 database related process linked to a SAP SM50 work process

Figure 2 ST06 DB related process -> SM50 process

1.5.1 How is a ST06 SAP-related process linked to a SM50 SAP work process

Figure 3 ST06 OS process -> SM50 process

1.6 Possible solution for mitigating CPU work load and achieving better load balance

Through above analysis, you identify the top peak period and top business transactions/jobs, you can consider following solutions to reduce CPU load and achieve better load balance:

  • Schedule – run t job in different time when system is less busy or change job frequency
  • Tune job/program logic and database operation – So the job/program is more efficient and use less CPU. This can include job variant change.
  • Workload balance/redistribution – run the job/program in another server/instance of the SAP system.
  • Upgrading hardware – more powerful server or more CPUs/Processors.

Upgrading hardware should be the last resort after all other options have been tried. For tuning ABAP program performance, you can refer to my post – how to do performance trace using SAP ST12 and how to tuning ABAP program performance if you like.

If external process is using a lot of CPU power, then you can use similar solutions as what we have for SAP related processes. Or you can simply terminate it and stop it depending on your scenario.

2 Use SAP ST06 to do Memory load analysis

Memory workload analysis is to make sure that there is enough free memory and free swap space (Virtual memory) available in the system by analyzing peak memory and memory usage pattern.

SAP ST06 can show you current server memory utilization and hourly average memory utilization for past 24 hours. Please refer to my post – how to run ST06 on ST06 screen navigation and understanding. Following is a part of past 24 hours memory history screen:

Figure 4 ST06 – past 24 hr memory history

To know current SAP server memory utilization status, you can just run ST06 transaction and refreshing the main screen every 10 seconds. If you would like to know which SAP process/user is consuming the server memory, you need to access mode list screen of SAP transaction ST02 – SAP buffer/memory monitor. ST06 provides top CPU processes but unfortunately it cannot provide Top memory processes.

Figure 5 ST02 mode-list

To know history memory usage, you can run SAP ST06 screen and navigate to past 24 hours memory screen. However, if you observed a particular period when the memory usage is a concern—that is all you can get from SAP ST06. You can use this information to schedule SAP transaction /SDF/MON to get memory snapshots for the period concerned, Then based on /SDF/MON memory snapshots, you can figure who and which processes are top memory consumption processes/users for the period in questions. That is why SAP /SDF/MON stands out as one of my favorite performance tool both for SAP production support and SAP development. Please refer to my post on how to run /SDF/MON for memory analysis if you would like to know more on it.

Figure 6 /SDF/MON snapshots

Memory load analysis also pays attention to swap space. I normally just check whether there are enough free swap space and hourly paging out rate. Hourly paging out rate for UX and Linux OS should not be over 20% of physical memory in general.

Here I assume that all memory consumption in a server are from SAP users or sap processes. SAP ST02 and SAP /SDF/MON is for analyzing memory consumption from SAP users in the instance/system where it is started. If there are other instances on one server or there are operating system level processes which consume a lot of memory, they would not be captured by SAP ST02 or SAP /SDF/MON. UX level or other sap instances need to be checked at the same time.

Possible solutions to mitigate performance concerns due to memory overload and achieve better SAP memory load balance are:

  1. Reduce volume – you might need to educate end business users or change job variant.
  2. Schedule – Run job/transaction in different time when there is less memory load.
  3. Redeployment – run the job in different instance or server.
  4. Tune the SAP job/program to reduce memory usage.
  5. More capacity – add in additional physical memory or swap space.

As for CPU load analysis, adding more capacity should the last resort when other options have been reviewed. If external process/task is causing issue, you need to work with owner and look into solution depends on actual scenario.

4 Other analysis Via SAP ST06

Based on ST06, we can do IO analysis based on and file space analysis. Objective of this analysis is to make sure that there is no hot spot or IO bottleneck by proper IO configuration such as spreading data out among system disc properly. You can refresh ST06 Main screen and pay attention to DISC with highest response time to observe whether a particular disc has high utilization for a significant duration and has a lot of process in waiting (queue length). You also can check past 24 hours disc usage history to find out whether a particular disc has an extremely high utilization and queue length. I have not run into such situation in my SAP performance work so far. No further insight can be shared. SAP system IO configuration is not my area as well.

Figure 7 -ST06 Disc with Highest response time

File space analysis is to check that we have enough free space at OS directory level. This might be critical for successful running of jobs/programs which need to output file to operating system level.

4. Further clarification

Up to now, I have covered on how to use SAP operating system monitor ST06 to do performance analysis: Identify existing/potential problems using SAP operating system monitor ST06 and continue ST06 analysis with other SAP performance tools. From ST06, you can access other SAP tools such as network traffic check which can be handy for troubleshooting network related performance issue.