Note 649327 Note Language: English

Analysis of memory consumption

Version: 5 Validity:
Valid from 16.08.2005

Summary
Symptom
An ABAP program is using an unexpectedly large amount of memory. This may also cause runtime errors such as SYSTEM_NO_ROLL, TSV_TNEW_PAGE_ALLOC_FAILED, SYSTEM_IMODE_TOO_LARGE, and so on.

More Terms
Memory, internal tables, reference variables, objects, garbage collection

Cause and Prerequisites

The memory is frequently used by internal tables. It can also be used by objects or data objects that were created dynamically using "CREATE OBJECT" or "CREATE DATA". These objects may in turn contain internal tables. When these objects are no longer required, they are deleted by the garbage collector and the memory space is released. However, this is only possible if the objects can no longer be accessed, that is, if all reference variables that point to the object are deleted. If several objects can access each other with references but can no longer be accessed externally, they will also be deleted by the garbage collector. The garbage collector is called on a heuristic basis, refer to Note 628303 for more information.

Solution
Sometimes, memory is used by the selection of a large amount of data in the database, the importing of a file that is too large or other similar causes. In other cases, you will have to debug the application. (1) You can, for example, display an overview of memory consumption using the following transactions: o o o o ST02 (tune summary) ST03 (workload) SE30 (runtime analysis) ST22 (ABAP runtime errors (when terminations occur))

Refer to Note 185185 for more detailed information. (2) Displaying the overall memory consumption in the Debugger In dialog programs, you can navigate to the debugger by choosing the menu option "System -> Utilities -> Debug ABAP". In the case of longer-running dialog or background programs, you can use the menu option "Program/Session -> Program -> Debugging" in Transaction SM50 to bring the program into the debugger. You can start background programs that are not active (for example, that have not been released) in debug mode in Transaction SM37 by entering jdbg in the command field. As of Basis Release 4.6, you can display the memory consumption by choosing "Goto -> Display condition -> Memory usage". Here you will find the memory
21.06.2007 Page 1 of 4

Note 649327 -

Analysis of memory consumption

used by ABAP variables, objects, internal tables and so on in the "used MM memory" field (Releases 4.6 and 6.10). In Release 4.5, you can display the memory consumption by choosing the menu option "Goto -> More screens -> Memory usage". (3) Memory inspector The "memory inspector" tool is available in Basis Release 6.20 as of Support Package 29 and higher, and in all subsequent releases. For earlier releases, refer to the explanations given later in this note. In the debugger, you can display ranked lists of the largest internal tables, strings, objects and dynamically generated (anonymous) data objects by choosing the menu option "Goto -> Display condition -> Memory usage". In addition to this, you can also display the reference variables for a (data) object or string that reference this object. To avoid frequent reallocation, you will, in general, allocate a little more memory than is needed at the moment. Therefore, we distinguish between allocated memory and used memory. An object may be very small but may contain a reference to another object that (for example) contains a large internal table. Therefore, we also distinguish between bound memory and referenced memory. (As of Release 7.00, memory that is exclusively referenced by an object is regarded as being bound memory. Thus, the bound memory is the memory that is released when the object is deleted.) In addition to this, you can create a memory snapshot, that is, you can save information about all internal tables, strings, objects and dynamically generated data objects that currently exist. You can compare this status with memory snapshots generated at other times using Transaction S_MEMORY_INSPECTOR. You can create a memory snapshot in any transaction by entering /hmusa in the command field. As of Release 7.00, you can also create memory snapshots by choosing the menu option "System -> Utilities -> Memory Analysis -> Create Memory Snapshot". In the debugger, you can use the menu option "Development -> Memory Analysis -> Create Memory Snapshot". As of Release 7.00, you can also start the function for comparing memory snapshots in the menu: "System -> Utilities -> Memory Analysis -> Compare Memory Snapshots" This opens a new window. 4) Displaying the largest internal tables In Basis Releases 4.6 and 6.10, you can display the largest internal tables by entering 'dis' in the command field of the debugger and ITAB-TOP25 as the area (scroll using the screen buttons). This also applies to Release 6.20, provided the system does not yet contain the memory inspector (see above). Refer to Note 185185 for information about releases before Release 4.6. (5) Statistics for objects As of Basis Release 4.6, you can display the number of objects that currently exist in the debugger as follows: Enter 'dis' in the command field and OBJMGR as the area (scroll using the screen buttons). Pay particular attention to the following values: o Last Live Objects (number of accessible objects in the last run of the garbage collector)

21.06.2007

Page 2 of 4

Note 649327 -

Analysis of memory consumption

o o

Objs Reclaimed in last GC Obj Allocs since last GC

Dynamically generated data objects (CREATE DATA) are not included, however. They are only included in the count as of Release 6.20 kernel patch level 907. There, the values are called: o o o O&Ds live in last GC O&Ds reclaimed in last GC Number of allocations since last GC

If you display an object in the debugger, you can use the menu option "Goto -> System -> Find reference" to determine the references to this object. (6) Calling the garbage collector As of Basis Release 4.6, you can start the garbage collector for test purposes from the debugger: "Goto -> System -> Garbage collector -> Execute" Occasionally, it may be useful to call the garbage collector explicitly in an ABAP program, refer to Note 580871 for more information.

Header Data
Release Status: Released on: Priority: Category: Main Component Released for Customer 18.08.2005 10:46:49 Recommendations/additional info Help for error analysis BC-ABA-LA Syntax, Compiler, Runtime

The note is not release-dependent.

Related Notes

21.06.2007

Page 3 of 4

Note 649327 Number 783870 771119 628303 580871 548845 185185

Analysis of memory consumption

Short Text Memory bottleneck despite deletion of large internal tables Reading large transport log file requires a lot of memory Heuristic for calling the garbage collector Calling the Garbage Collector explicitly Internal modes uses more than 2 GB Application: Analysis of memory bottlenecks

21.06.2007

Page 4 of 4