Analysing ABAP performance by Call Stack

[setu_jha]

In this blog post, I’ll walk you through the process of performing a root cause analysis for performance bottlenecks in ABAP applications. We'll focus specifically on how to evaluate the ABAP application call stack to identify the underlying issues that may be impacting system performance. By understanding the structure and behavior of the call stack, you can pinpoint inefficient code, redundant processing, or problematic custom developments — ultimately leading to more optimized and responsive SAP systems.


1. ABAP stack for running user session

The call stack is a valuable tool for root cause analysis in ABAP applications. It provides the sequence of the class methods, subroutines, or function modules that lead to an error or issue, starting with the current program and going back to the initial starting point. This is very important to understand where the problem begins and who the responsible developer is.

 Example: The application SAPLZHK01 is responsible for the NRIV lock wait.

->  View the call stack in the work process info.
Select a work process and then execute the WP-info in the 'Go To' menu or by double-clicking on it in the ALV.

-> To generate a call stack in work process diagnostic file 
Execute the write stack in SM50 in the Administration -> Work Process -> Write Stack menu.

-> Server Snapshot
Server snapshot (also known as SAP Kernel snapshot) is a feature available since SAP NetWeaver ABAP Kernel 740. It is a concept of the NetWeaver ABAP application server which aims to save the most important system information automatically when the system is in abnormal situations. It saves the SM21 system log, ABAP stack, C-STACK,  and developer trace files in a single ZIP file. It can also be triggered manually via SM50 menu Administration -> Snapshot -> Create

-> Trigger the snapshot from the operating system using the sapcontrol command

Tools for the offline analysis

- SAP Microsoft Management Console 
- Kernel snapshot analyzer

-> Server Snapshot
The server snapshot file can be accessed via the transaction code SNAPSHOTS or SM50 menu Administration -> Snapshot -> Administration. The snapshot file can be read directly in SNAPSHOTS, or offline analysis tools like SAP MMC and Kernel Snapshot Analyzer

-> ST12 ABAP trace

2. ABAP stack of the user session in the past

Use /SDF/SMON to extract ABAP stack of technical issues in the past.

SMON (tx /SDF/SMON) is to analyze past performance problems or to monitor the system. To use SMON for analysis, it must be scheduled first before the desired analysis period or already running when the issue occurred.

SMON is the successor to /SDF/MON and collects additional data including the ABAP stack. SMON is available as of Software Component ST-PI Release 740 Service Pack 0002

How to Schedule SMON: SAP Note 2651881 - How to configure SMON for performance monitoring and analysis.

The monitoring data is stored mainly in DB tables /SDF/SMON_HEADER and /SDF/SMON_WPINFO for the last 3 days and then stored to /SDF/SMON in the compressed format during the predefined retention period. The call stack information is stored in the DB table /SDF/SMON_STACK and /SDF/SMON_STACKH

Typical SMON daily scheduling:

Execute the transaction /SDF/SMON and check whether the SMON was running in the analysis period in question 

The aggregated work process overview

Use case examples
- Analysis of the delay of a batch job already finished
- Find the most expensive operation that led system’s high load in the past

Find the Call Stack in SMON

Display SM50 data with the filter ‘Only records with Call stack’

Direct SMON DB table access example

SMON DB tables

Limitation 

Example
An intermittent performance issue in S4/HANA when calling the HTTP RFC destination of the SAP ETAX BTP solution.

The work process overview history data in /SDF/SMON offers enhanced clarity regarding the issue : The work process was executing the same batch job, and it was on SAPLHTTP_RUNTIME most of time and the call stack was the same for all snapshots. However, it was not a ‘hanging’ situation for a single HTTP call because the work process performed different actions between snapshots

Example 
An intermittent data inconsistency issue within CO and SD components. The only technical finding was that when the issue occurred, the V1 423 message (an A type message) appeared in the system log while executing CO BAPI functions. However, the specific call stack linking these events remained unidentified.

Identifying the call stack :
- Find the ABAP include program that generate that specific message using SE91 where used list
- List up date, time, instance name and the work process number in the syslog
- Search available /SDF/SMON call stack based on the information collected

 

Example
Analyzing issues that happened in the past - an unusual long run time of a particular batch job. 

Root cause analysis using the /SDF/MON snapshot data
- Used /SDF/MON because /SDF/SMON was not available in the system (Call stack is not available in /SDF/MON)
- Analyze the SM50 activity data using the instance name and the work process number that ran the batch job
- Used work process activity aggregation to identify the root cause of the performance issue

Example
Analyzing issues that happened in the past 
ENQUEUE performance issue in the past, the issue was more than 2000 work processes were stuck at ABAP program SAPLSENA waiting for the response from the standalone ENQUEUE server.