Expand +



What You Don't Know About Memory Can Hurt You: A (Re)introduction to Efficient Memory Computing for Programmers and Developers

by Winfried Schleier | SAPinsider

October 1, 2007

Despite the advent of 64-bit operating servers, memory shortages can still be a very real problem for programmers and developers. Find out why it is important to look beyond session context size – often considered the main culprit of memory problems – to find the real major cause of memory shortages: memory leaks. Find out which SAP tools will help you prevent these leaks, and which ones will help deal with existing memory leak problems.

With the arrival of 64-bit operating systems, many developers — especially those who develop server software in virtually foolproof development environments like SAP's — have moved memory to the back burner, no longer thinking about it when designing applications.

SAP's multi-tier server software is architected to optimize its multiple tiers and save CPU cycles and communication steps; it uses buffers and caches to avoid unnecessary communication between its different layers. These buffers and caches, though, can use potentially large amounts of memory when multiple users are concurrently logged on to a system and are executing business transactions. This is because the content of those transactions must be kept in memory to guarantee fast response times.

These demands have been known to create memory shortages with 32-bit operating systems. And despite popular opinion, the arrival of 64-bit computing is not the silver bullet for memory concerns. No matter what the hardware's processing power, memory capacity currently cannot keep pace with the speed of CPU development. Given memory's sheer expense, throwing more gigabytes at the problem is typically not the answer — you must use memory wisely.

This article focuses on memory consumption and optimization in the ABAP virtual machine (VM); it is not about hardware sizing. Many of the considerations discussed here also apply to other runtime systems and programming languages, like Java.

Assign a Monetary Value to Memory to See What a Critical Resource It Is

Consider a typical entry-level system server with four dual-core CPUs, a redundant power supply, three years of basic support, and a maximum of 64GB of physical memory that can be plugged in to it, among other standard server features.

Ordering this server with 32GB of main memory typically increases the server price by approximately 150%;1 ordering the server with 64GB of main memory increases the price by approximately 300%.

This simple example demonstrates how critical it is to use memory carefully, even in today's server systems designed for multi-user enterprise applications. We would even argue that it is especially important in today's server systems. Why? Think about the upcoming quad-core CPUs. They will essentially double the computing power of the dual-core server. But this also means that approximately twice the amount of memory will be needed to make full use of this CPU power. As long as there is no new generation of memory modules available to offer twice the memory capacity, the result will be unbalanced systems. All applications that need 64GB of memory today will not be able to exploit the CPU power of the new quad cores.

Why the Focus on Low-End Servers?

Many companies use cheaper, entry-level servers or hardware blades. These types of servers are also used to build up the infrastructure of hosted systems. Hosting is usually done by running one or a few (typically three to five) dedicated tenants per server,* or by running multiple tenants on a virtualized hardware environment that consists of multiple, cheap servers.

High-end servers that can hold much more memory are available, of course. But these servers are usually also designed to work with a much higher processor capacity, meaning the ratio of memory to CPU power should be in the same range. Also, the price of these servers is usually factors higher than the price of the entry-level servers.

* See for more information.

Memory Is an Important Resource: Use It Carefully

Given how costly memory is, SAP software architects and designers — as well as programmers that develop solutions based on the SAP Web Application Server — should streamline their memory usage during the development process.

But here's where ABAP programmers often get caught: As a modern programming language, ABAP does not burden developers with memory allocation at all; it happens automatically. As a result, developers' understanding of this resource might diminish, and some forget about memory consumption entirely.

To take a more proactive approach to memory in their programming work, developers must first refamiliarize themselves with how memory problems happen.

Look at Session Context Size — But Don't Stop There

When developers uncover memory issues, they typically assume that pure session context size is the root of the problem. Yes, session context size is important, as we'll explain in this section. But as you'll learn later, it's rarely the major culprit.

Within dialog-based applications — your typical sales order entry system, for example — a large number of users are logged on to an application server, which processes users' requests. Whenever a user is working with the system, there is always a delay — called think time — between when the user enters new information on screen, checks it, and sends it to the application server. For the application server to respond quickly, the current context of the user session must be kept in main memory during the think time. Only during longer breaks would it be suitable to allow the content to be paged out to file.

The combination of a high number of dialog users working with the system and the need to store their session contexts in memory usually demands a high amount of physical memory. As the number of dialog users per server increases, the size of each single user session context becomes more and more important to optimize. This is especially true for core business processes, such as creating sales orders or sales quotes, performed by many users in a system.

To help you optimize session context and track down the top memory consumers, SAP provides the ABAP Memory Inspector. Generally available with SAP NetWeaver release 6.40,2 the Memory Inspector is a tool for analyzing memory consumption in ABAP programs. In a future SAP Insider article, we'll detail how you can use this tool to reduce memory consumption.

The more sophisticated your application's UI, the greater the risk of a memory leak — and the more proactive developers need to be to prevent that risk.

Memory Leaks Are the Main Culprit

The larger source of memory problems, though, lies in applications with a long total run time. The longer the run time, the higher the probability that a memory leak will occur and that the memory usage of the corresponding internal session will grow until it reaches a system-defined upper limit (see sidebar below).

What Is a Memory Leak?

The term memory leak describes a situation in which a program continues to allocate pieces of memory but fails to release them when they are no longer needed. For long-running programs, even a small memory leak can result in high memory consumption, occupying memory so it is no longer available for other programs or users (see figure below).

The impact of a memory leak on response time is hard to detect if the overall system memory is not at its capacity. Rather, memory leaks are typically only noticeable in multi-user operations when the whole system memory is used up and the operating system starts paging.

This is what differentiates memory leaks from response-time problems caused by high CPU consumption. If the processing of a certain dialog step needs five seconds of CPU, even a single user will recognize it; with memory, that's not the case.

Forgotten, uncleared memory — a memory leak — accumulates over time until, eventually, all physical memory is consumed

Certain programs are more prone to memory leaks than others. Developers must be aware of potential memory leak problems in two primary categories of long-running programs:

Batch jobs that sequentially process huge quantities of business objects — Consider that your billing program executes batch jobs for the daily billing run of hundreds of thousands of delivered orders, or for the month-end closing of millions of bank accounts. If the billing program keeps internal memory objects with order data or customer data and doesn't refresh them when a new business object begins, a memory leak occurs and the memory consumption will grow continuously. To help you detect these leaks, the ABAP Memory Inspector provides functionality to analyze the memory increase between two timestamps.

Endless transaction patterns, common within user-friendly, workcenter-style UIs — To define this pattern, let's first look at its predecessor, the simple transaction pattern. In the classic SAP GUI days, you'd use one transaction to create a certain type of business object — a purchase order, for example. Other transactions existed to modify the purchase order, or to display it. This setup was optimal for data-entry clerks who simply needed to create one purchase order after another. In these transactions, upon using the ABAP element LEAVE TO TRANSACTION, the entire session context was cleared completely after one business object was processed. With this simple transaction pattern, the ABAP runtime environment guaranteed that the whole content of the user session — besides the logon and authority information — was cleared.

In contrast, today's transactions usually offer a kind of work center for a certain business object or group of business objects (see Figure 1). In one part of the screen, the UI integrates search functionality, either for predefined searches like "My Open Orders" or for freestyle searches that allow the user to search for orders according to a set of attributes. Within the UI, users can work with the resulting hit list in another part (or tab) of the screen. Users can then process open orders in their worklist sequentially, without having to repeatedly execute searches.

Figure 1
A sample of today's user-friendly, workcenter-style UIs, common sources of endless transaction
patterns — and potential memory leaks

In this type of UI, one session context typically holds both the worklist content information and the information for the current order. Every time one order is processed, the part of the session context that holds the order data must be cleared, while the worklist part of the session context should be retained. This transaction pattern is called an "endless transaction" because the session context now lives until the user stops this loop of processing one order after the other.

With up to 1,000 different program units (mainly classes and function pools) that are needed to process an SAP business object — and that may need to react when the user signals that the transaction is finished — clearing memory correctly is absolutely critical for the prevention of memory leaks. Application programmers must control the clearing process themselves (see Figure 2). So how do you clear the data stored within the user session?

Figure 2
Understanding the difference between transaction types helps programmers to proactively prevent memory problems during the development process

It is possible to use two sessions for these workcenter-style applications: one that controls the worklist content and another that controls the processing of a selected business object. But synchronization must be established between the two sessions. For example, if one of the open orders has been processed, it should no longer be displayed in the worklist of open orders.

Prevent Memory Leaks with Internal Buffer Cleaning

If you create a new endless transaction for a customer or add new functionality to a standard SAP process, you must understand how to implement internal buffer cleaning to prevent memory problems.

In this context, internal buffer refers to data stored in the user session itself. It should not be confused with application server-wide buffers like ABAP program buffers or SAP table buffers. Typical examples of internal buffers in a sales order entry application are buffers for master data — business partner data or material master data, for example. This type of master data is typically of interest to many different program units and consumers.

The recommended method to clean internal buffers is to use the end of the SAP Logical Unit of Work (SAP LUW),3 which usually coincides with the end of a work package's processing (in batch processing) or with the end of one business object's processing (in dialog processing).

If this applies to your development, register the program that controls your buffer content for the ABAP event TRANSACTION_FINISHED in class CL_SYSTEM_TRANSACTION_STATE. The ABAP runtime layer will then automatically raise the TRANSACTION_FINISHED event at the end of an SAP LUW for:

  • A successful end of the SAP LUW by the ABAP keyword COMMIT WORK

  • A termination of the SAP LUW via the ABAP keyword ROLLBACK WORK

This method is ideal for proactively preventing memory leaks. But what if you detect a memory leak issue in your already-developed program or application?

Using Web Applications? Then Pay Even Closer Attention to Memory and Session Management

A word of caution if you frequently implement stateful Web applications, such as Business Server Pages (BSP) applications, Java Server Pages (JSP) applications, and Web Dynpro applications, which are all launched in a Web browser instead of SAP GUI. When launched, most stateful Web applications generally run in an endless transaction mode, which means they are prone to memory leaks.

With Web applications, though, there is no equivalent to the ABAP statement LEAVE TO TRANSACTION to clear the session content quickly and reliably. If a Web application does not rely completely on the internal buffer cleaning process, you'll have to implement session restarts yourself.

With BSP applications, you can realize a session restart by changing the BSP session state dynamically from stateful to stateless (which terminates the session) and by including a piece of JavaScript in the last HTTP response of the old session to later trigger the start of a new session. Comparable mechanisms also exist for applications written in Web Dynpro for ABAP.

To Solve Existing Memory Leak Problems, Consider a Session Restart

The ideal solution for a memory leak problem is to first use the ABAP Memory Inspector to analyze all possible situations, and then to eliminate memory bugs in all participating programs by implementing the proper buffer refresh.

But for a quick fix, an intermediate solution is to implement a session restart mechanism that triggers after a certain number of business objects have been processed, or after a certain memory threshold is reached (see class CL_ABAP_MEMORY_UTILITIES).

During the restart, the part of the session context that needs to be kept — worklist content, for example — is stored in a part of the memory that will survive the restart process. Afterward, a LEAVE TO TRANSACTION event will trigger the restart, and finally the saved context content will be imported.

To implement the context saving, ABAP developers can use two kinds of memory:

  • Export/Import Shared Memory, available via the ABAP language element EXPORT TO/IMPORT FROM SHARED MEMORY. Transferring data to and importing data from the Export/Import Shared Memory is done via copying, so we recommend that you use this type of memory if the amount of data you need to retain is small (less than 200KB).

  • Shared Objects Memory, available in the single-writer, single-reader mode without area versioning.4 Since no data need be copied, but will be accessed via reference, use the Shared Objects Memory if you need to retain larger amounts of data. You can also use Shared Objects Memory when you need to retain complex networks of ABAP objects, since Export/Import Shared Memory cannot keep these object networks. If you use Shared Objects, put the data into the Shared Objects area upon first use of the object instead of transferring it at the time of the restart.


It's time to dispel two common misconceptions about memory: that the arrival of 64-bit computing signifies the end of memory problems, and that pure session context size (that is, presuming there is no memory leak) is the root cause of most memory concerns.

In theory, the advent of 64-bit operating systems should mean that we're closer to freedom from memory shortages. But the physical availability of memory today much more closely resembles the capabilities of a 36-bit operating system (64GB = 236 byte = 36-bit addresses) than the much-anticipated 64-bit operating systems now available. Software capabilities are simply outstripping hardware capabilities.

And memory leaks are a much graver memory problem than the size of a user session context. The reasons are numerous: Memory leaks make it impossible to do system hardware sizing. No productive system can be run if important business scenarios suffer from memory leaks; sooner or later, all physical memory will be used up and the operating system will start heavy paging activities. Memory access will be slowed down from nanoseconds (access to main memory) to milliseconds (disk access), immediately affecting system response time.

Good, proactive programming practices can help you avoid memory leaks in the first place, and a comprehensive set of ABAP tools can help identify leaks if they do occur. If, despite good programming and memory leak detection, you still have memory problems, stay tuned for an upcoming Performance & Data Management Corner column. Here, we'll focus on the ABAP Memory Inspector, which will speed up the analysis of memory leaks considerably.

1 Over one without any memory (a hypothetical situation, of course).

2 The ABAP Memory Inspector is also available with SAP NetWeaver release 6.20, support package (SP) 29.

3 A logical unit of work (LUW) is an indivisible business process; it is performed either completely or not at all.

4 4 For details, see or go to ? SAP NetWeaver and search for Shared Objects.

Additional Resources

"64-Bit Servers — No Longer Just an Option, but a Necessity, for Enterprises Running SAP" by Franz-Josef Fritz (SAP Insider, July-September 2006,

"Analyze Memory-Related Problems in Your ABAP Programs in Less Time and with Less Effort Using the ABAP Memory Inspector" by Christian Stork and Wolf Hagen Thümmel (SAP Professional Journal, November/December 2004,

The SAP Administration and Infrastructure 2008 conference in Orlando, March 26-28, 2008, offering sessions to help you wield memory to ensure the high performance of your SAP systems (

Winfried Schleier ( studied at the Friedrich-Alexander University of Erlangen-Nuremberg, Germany, and received his Ph.D. in Compu-tational Physics. Winfried joined SAP AG in 1994 and has been a member of the Performance, Data Management, and Scalability team from the start. His areas
of responsibility include performance, benchmarking, and sizing of different SAP solutions. Currently Winfried is concentrating on methodologies and tools for memory optimization in the ABAP VM.

An email has been sent to:

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!