The ABAP Memory Inspector

The Memory Inspector comes in two flavors:

• Use the Memory Inspector standalone transaction (S_MEMORY_INSPECTOR) to analyze and compare memory snapshots. A memory snapshot records the memory usage of an ABAP program at a particular point in time.

  The Memory Inspector transaction is the ideal tool for comparing memory snapshots, looking for memory leaks, and verifying the correct memory usage of your application.

  Collect memory snapshots from the application at different points in time. You can then see in comparison exactly where and how memory usage changed.

• Use the Memory Inspector in the new ABAP Debugger to analyze memory usage in real time in the program you are debugging. In the Debugger, you can jump between the display of memory objects and the values of the objects in the Variables displays.

  You can also create and compare memory snapshots — also for later analysis — while you are debugging a program.

  Here is documentation on the Memory Inspector in the new ABAP Debugger.

  Note For information on the memory architecture of the ABAP AS, please see SAP Memory Management.

The Memory Inspector is ideal for analyzing memory use. But how can you scan for 'fat' applications that grow because of a memory leak or that use large amounts of memory?

There are two tools for scanning for high memory consumers:

• Use the User List (transaction SM04) to monitor memory use online and in real time. The Memory Consumption column in the display shows the total memory allocated to the user.

  Use SM04 to monitor long-running transactions that stay open for repeated use and to monitor the memory consumption of long-running background jobs.

• Use the SAP Workload: Single Statistical Records — Overview (transaction STAD (interface in English only) or STADWD (translated interface) for the Web Dynpro version) to scan for high memory users among completed transactions.

  The selection option Show all records, grouped by business transaction may help you by organizing the display by transaction. The column Memory used (kB) shows the maximum memory used by a transaction in each dialog step.

  Use STAD when you have had memory-related short dumps such as SYSTEM_NO_ROLL or TSV_TNEW_PAGE_ALLOC_FAILED or when you have observed Dialog work processes in PRIV status. The statistic records in the time immediately preceding these events may show which programs were consuming too much storage.

It's important to remember that memory problems almost never appear during development or integration testing. Also, ABAP is inherently resistant to memory leaks, since most transactions and requests run discretely and finish fast, so that their resources are quickly freed.

The lessons:

• You have to go looking for trouble. Observe your ABAP programs under conditions of stress- or scalability-testing or in production systems.
• Focus your attention on transactions and programs that may run for long periods of time. There is no need to check transactions or services that are used discretely.

  Check transactions that stay open and are used repeatedly for operation after operation. Check reports that run in background jobs and which may be expected to run for hours or even days.