Skip to Content

Step by step instructions on how to use ST12 trace for analysis 2436955   

In the first place, you have recognized this KBA from our previous post! Yes, that’s right! Our customers love using ST12 for their performance problems. This KBA will take you step by step on how to take an ST12 trace and how to analyze it so that you can pinpoint where your problem may lie. There is a reason why this KBA continues to take the throne and that’s simply because it’s the grand tool to solve your problems.

It can also be utilized to trace a transaction or a program at the moment it starts. This transaction would be very useful in finding how much runtime is allocated for each ABAP Step and DB activity, which in turn will be useful for optimizations or identifying and assist in root cause analysis.

Make sure you have this tool in your arsenal. Let’s move on.

 

 

 

High RFC time: Performance troubleshooting 2418936  

Just like the ST12 KBA, in second place is a KBA all about High RFC Time which was also in our previous TOP TEN KBA’s. To give you a quick summary of what you’ll find in this KBA, we will show you how to interpret the high RFC times seen through STAD and ST03/ST03n. This may be one of the most difficult topics in General Performance as high RFC time can be caused by many, many variables. Some may be:

Network performance issues
The result of communication and high data volume issues

Slow running jobs between different SAP systems (for example ERP and BW)
Indicated by high roll wait time in the ST03 monitor.
In this scenario, a job that is running between SAP systems can take a long time to complete the target system, which can be an application, hardware or database specific issue.

Unavailable RFC resources
Individual RFC resources are overutilized on the target system which can generate high wait time.

A misreported response time which is not related to an actual performance issue, but rather a bug related in manner.
In this case, the response time will be unrealistically high.

High RFC time is provided in Early watch alert.
An Early watch alert will highlight RFC response time as yellow if it exceeds the monthly average threshold of 2400ms and red if it exceeds the average threshold of 3600ms.

 

 

 

 

How to use the SAP Performance Monitor SDF/MON tool to analysis 2383809   

Another tool to assist you with your performance troubleshooting is /SDF/MON, if you do not already use this, you should start. What it does is record SM50 snapshots so that you can see your system perform at intervals (set manually) from the past.

Use this tool if you are having performance problems through the day and not all the time. Use this tool if there is a job at night and you want to see how the system reacts in according to the job. Use this tool if you want to see if you have any work process shortage. It’s a great tool to get an overview of the system at all times of the day.

This tool does not add any extreme overhead unless certain parameter is set such as CPU per session

 

 

 

Performance problems with OLE_FLUSH_CALL, how to analyse 2457530 

Moving up to fourth place this month is a Knowledge-Based Article completely written about OLE_FLUSH_CALL. I’m sure you have all seen this line before when you are analyzing ST12 traces. Let us help you understand why this shows up and what the next step you can do to find out if this is normal or the delay is caused by front-end programs. Here is a quick summary of what the KBA will cover:

A few points that are covered in this KBA are:
-Determining if the runtime is the problem
-The number of times OLE_FLUSH_CALL is called
-Network Infrastructure and Traces
-SAPGUI Version management
-Performance GUI Traces

Add this KBA to your list of staple KBAs, it may help you in the near future.

 

 

 

 

How to analyze high GUI time on SAP systems  2428353

Another favourite of SAP employees and our customers is this KBA dedicated to the troubleshooting of High GUI time seen throughout STAD and ST03n monitors. It continues to gain traction as one of the most popular KBA because of how often problems like this happen.

It walks you through a single transaction or programs in STAD which can also be found in the Workload Monitor. There are many scenarios that you may see high GUI time including:

-Large volume of data transfer from the application server to presentation servers (frontend GUI).

-Low network transfer rate between application server to presentation servers (frontend GUI).

-Long time on executing/interpreting the RFC calls on presentation servers (frontend GUI).

-The display time on the frontend is long due to the performance of frontend PC is considerable bad.

Have a short glimpse of how to use tools like Performance trace with this KBA.

 

 

 

Performance issue with RFC processing with a large amount of entries in ARFC Table 2548815

A simple yet cumbersome problem, this KBA will go over the performance issues seen from RFC processing a large amount of entries in ARFC tables. There is a report that can be run to clean up the table which is described more in the KBA.

Make sure you have this in the back of your toolset.

 

 

 

Performance analysis of external RFC server programs (registered program) 2426336

At seventh place, we have one of favourite KBAs. Whether you have problems in parallel RFC processing of an external RFC destination in SM58 or the connection test of External RFC deestination in SM59 with high response time, this KBA will assist you with all that The error message you may see will look like this:

Error Details ERROR: timeout during allocate of registered program
Error Details LOCATION: SAP-Gateway on host Hostname/ sapgw00
Error Details DETAIL: TP Test_Program init/busy for more than 60 sec

This happens due to the poor network performance between RFC client and external RFC server, or the external program which registered on the SAP gateway
is currently being used by other process,RFC client which calling the external RFC destination cannot access the registered gateway program until the registered
program was released for accessing.
Otherwise,the accessing to external program failed with error””timeout during allocate” when exceed the gateway timeout(parameter gw/reg_timeout).

If you have this problem, get to fixing with this KBA.

 

 

 

High Wait Time analysis in SAP system 2432675

Coming back in eight place, we have “High Wait Time analysis in the SAP System” which covers the ‘Wait Time’ value seen in Business Transaction Analysis (STAD), Workload Monitor(ST03/ST03n) or Solution Manager.

The answer to most problems like this are :
1. No sufficient work processes configured for the system
2. Work processes were occupied by long-running programs

Find out if these solutions are applicable to your problems with this KBA.

 

 

 

Survival Guide for performance analysis on SAP system 2442365

In ninth place, we have the “Survival Guide for performance analysis on SAP Systems”, which I find surprising because this is truly the bible for general performance problems. Refer to this guide whenever you are looking for information on General performance and this includes cross-platform integration problems.

What is Cross-Platform Integration Problems? A great example I like to use is a CRM UI user trying to access a list of the employees but the loading is far too slow. The goal of this guide is to assist you in finding if the problem lies in the frontend, network, application layer, or the database layer and more.

This documentation covers:

-System initial analysis
-Key performance analysis transactions
-Workload analysis
-Network performance analysis
-Database related performance analysis
-Useful performance analysis tools
-SAP service process

 

 

 

 

5 second delay in Enqueue requests with Antivirus software on Windows 2543437

A new KBA that focuses on slow system performance where many work processes are delayed. If you do not know if this applies to you, the following symptions can be found:

  • SM66: In Work Process Monitor SM66, the status of program SAPLSENA is ‘On Hold’/’Stopped’ with reason ‘ENQ’
  • STAD: A normal Enqueue request should take less than 2ms per call. When you search for affected tasks in STAD, the following screenshot shows a single record in detail. It shows very high Enqueue time
  • SM12 -> Extras -> Diagnosis :  The symptom also presents itself in SM12 -> Extras -> Diagnosis. Usually, the test should finish within 1 second. But it’s very slow now.
    If you collect Enqueue logs, you will find 5 seconds delays.

 

 

 

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

Leave a Reply