Skip to Content

Next Generation ABAP Runtime Analysis (SAT) – How to analyze memory consumption

SAT is the transaction name of the new ABAP Runtime Analysis Tool, which is one of the most significant improvements in ABAP in the NetWeaver 7.0 EhP2. For those of you who are already familiar with the transaction SE30, the former ABAP Runtime Analysis Tool, transaction SAT is the successor of SE30. In SAT, ABAP’s Runtime Analysis has been reworked by SAP’s R&D department and has been enhanced with effective new analysis tools and features. 

SAT offers benefits such as a modern state-of-the art UI, new analysis tools, easy navigation between tools and so on. This third blog of the series about SAT devotes itself to the analysis of memory consumption problems and demonstrates how the new tools of SAT help you to perform an effective memory consumption analysis of any ABAP application.

 

These series of blogs about SAT are suitable both for newbies and for experienced SE30 users. You can find other blogs from these series about SAT here:

 

Next Generation ABAP Runtime  Analysis (SAT) – Introduction

Next Generation ABAP Runtime Analysis (SAT) – How to analyze performance

Next Generation ABAP Runtime Analysis (SAT) – How to analyze program flow

 

If you want to see a live demonstration of SAT, take a look at this short video:

 

Let’s start with a sample usage scenario. Imagine an object-oriented ABAP program whose task is to process shopping orders.  Each order consists of some kind of master data and purchased items. After an order gets processed by the program, the program should retain only the reference to the master data and discard the shopping items.  Since the program holds in memory only small amounts of master data, we don’t expect any memory leak there. Unfortunately after we run the program and try to process the first 100 orders, the program crashes with the short dump shown below.

The short dump tells us that the attempt to insert some data into the internal table failed due to the unavailability of memory. Our task is now to find out where the excessive memory consumption took place in the program.

 

 

Now let’s see how to use the new ABAP Runtime Analysis (SAT) to analyze memory consumption problems in an ABAP application.

 

First we must start the ABAP Runtime Analysis (SAT) and create a measurement variant.

1. Start the ABAP Runtime Analysis (SAT) via System -> Utilities -> Runtime Analysis -> Execute or call the transaction “/nsat” directly.

2. Type the name of a program into Program field

3. Choose Eval. Immediately to start the analysis right after the measurement

4. Create our own measurement variant:

  • Type a name into Variant field and press the Create button
  • Set aggregation to None on the Duration and Type tab
  • Switch on Measure Memory Usage on the Duration and Type tab to trace memory use
  • Select Processing Blocks on the Statements tab so as to reduce the size of the trace by tracing only processing blocks.
  • Save the variant

5. Press Execute button to start the measurement.

 

 

Since the program crashed with 100 orders, we will try to run it with a smaller amount of data in order to localize a memory leak. For example we will use just 5 shopping orders instead of 100. If the program doesn’t crash with 5 shopping orders, then we will be able to analyze its memory consumption with SAT.

Let’s take a look at the measurement results with the Processing Blocks Tool. By using Critical processing blocks button you can display runtime or memory usage hotspots.  We would like to display all processing blocks, whose memory usage exceeds 25% of the total memory consumption for this internal mode. These critical processing blocks get marked in red. The memory consumption is displayed at the beginning and at the end of each processing block. If you open the entry of a critical a processing block, you can see where your methods have allocated the memory or where the memory has become available. You can also restrict the view to this subarea to analyze it more deeply (Confine to Subarea  button).

 

 

If we look at the critical processing blocks, we will see that the constructor allocates memory. But this is the expected behavior since our program must create orders before processing them. If we display a critical processing block in the Call Hierarchy Tool we will see that after execution of the FINALIZE_ORDER method the memory usage doesn’t get reduced. And this is strange, since we expect that the program retains only a small amount of master data and releases the memory that was used for purchased items.

And if we double click on the trace event with FINALIZE_ORDER we will see its source code. The “order->id” (which is the master data) gets appended to processed orders (“processed_orders” in the source code), the order (“order” in the source code) gets deleted, and a garbage collection is called. So far it looks correct. But if we examine the “order->id”, we will see that the master data keeps a reference to the order data. Therefore garbage collector cannot collect the order data, because it is kept alive by the master data. The source code has even more dependencies: the order data keeps a reference to the master data; we therefore have a cyclic dependency between master data and order data.

 

 

In this way you can find memory hotspots in an ABAP application with SAT.

 

Best Practices for a Memory Consumption Analysis

 

When analyzing memory consumption of your application with SAT remember the following:

 

  • Perform non-aggregated measurements with option Measure Memory usage to trace memory consumption

 

  • Restrict the size of the measurement results by using variants

 

  • Use the Processing Blocks Tool in combination with Call Hierarchy Tool to detect memory hotspots. In the Processing Blocks Tool you get an overview of the memory usage of processing blocks and within individual processing block. You can also see memory hotspots (marked in red). The Call Hierarchy Tool displays memory consumption of events in the call hierarchy. You can also focus this view on the memory consumption in subareas.

 

  • Use the Call Hierarchy comparison tool to check the scalability of your application. Execute your application a couple of times and then compare the traces. For example start your application, perform the operation you want to measure (e.g. process an order) and execute a first measurement with SAT (e.g. use “/ron” and “/roff” commands to start and stop a measurement). Then perform the operation again and execute a second measurement with SAT. To compare the trace results use Call Hierarchy comparison tool. You can access it on the Evaluate tab of the SAT initial screen by selecting two compatible measurements and pressing Compare Call Hierarchies button.

 

 

 

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