The Memory Areas in a SAP System SAP BASIS

As explained in the previous section, you are now able to identify performance issues that affect the system in general and specific problems in transactions or programs. When examining the response time of your system and identifying that the load and generation time is excessive, it is likely that there may be problems related to memory management and buffer utilization. This may be caused by wrong parameter settings or a wrong configuration in an instance. In this section, our goal is to identify those problems related to memory management and buffer configuration in a SAP system.

The Memory Areas in a SAP System

In a SAP system there are a series of buffers and memory areas that can be configured via parameter settings in the Instance Profile. Buffers are areas of temporary storage that help to access more rapidly data and execute ABAP programs faster. Likewise, there are memory areas used by ABAP programs during its execution that can be configured help to make the most out of the hardware resources of a server and achieve optimal performance. Let's define those areas and how to configure them. It is important to understand that every server has a certain amount of physical memory or RAM and a certain amount of swap space that can be configured at the operating system level as a page file.

This swap space or page file "enlarges" virtually the physical memory and the whole set can be seen as "virtual memory." The memory areas that can be configured in a SAP system will be addressed in the virtual memory of a server. It is also very important to understand that there are several dependencies with the operating systems that are used. However, the general concepts apply to all operating systems and the parameter settings to configure the memory areas are almost all the time the same and independent of the platform. Ensure that you consult the installation guides and the available SAP Notes for specific parameter settings that apply to your platform.

SAP Memory Areas and Their Allocation Sequence

When a user needs to execute an ABAP program or any transaction, a work process will actually execute that program or those programs carrying out the task, extending the user context of a user and using the SAP memory areas that are defined via parameter settings, but indeed it will be consuming the physical resources, the virtual memory. Every work process that is configured in an instance will be consuming a certain amount of memory, the roll area, defined by the parameter setting zttz/roll_area. A very little part of the roll area is defined by the parameter ztta/roll_first. This is the very first area consumed by a dialog work process.

A very large memory area set by the parameter setting em/initial_size_MB defines the Extended Memory, where most or all of the user context of the user will reside while executing a program. After consuming the first roll area defined by ztta/roll_ first, a dialog work process will start allocating extended memory. It can consume as much extended memory as is available or until it reaches the quota defined by ztta/roll _extension.

Finally, part the heap memory defined by abap/heap_area_total is allocated by the dialog work process. It can allocate as much heap memory as is available or until reaching abap/heap_area_dia. If the program is not finished after exhausting these limits, the program will abort with a dump that will comment about the memory exhaustion. Otherwise, the program finishes successfully and the memory areas that were allocated get released. However, there is an exception: if the dialog work process starts allocating heap memory, it enters into private mode (you will see status stopped in SM50 or SM66 and Reason "PRIV"), getting locked to that user until the transaction is finished, even if several dialog steps are necessary to complete it.

If this is the case, after a program finishes, the heap memory gets released, but not the swap space that was allocated before, creating a gap in memory and starting a snow ball sequence that can cause severe performance problems. In order for the swap space to get released, the work process that allocated all that memory must be restarted. You can restart a work process manually, but in order to avoid administration efforts, the dispatcher can do it automatically. By setting the parameter abap/heaplimit to a certain level, when a dialog work process reaches or passes that amount, it gets flagged. After finishing the program, the dispatcher detects it and restarts the work process.

To avoid overhead, it is convenient not to set this parameter too high, so you ensure that work process that consume large amounts of memory are actually restarted so the swap space gets released; but not too low either, or the dialog work processes that reach heap memory will be constantly being restarted.

Monitoring the Memory Area Consumption

If, after examining the response time of your system, a lead takes you to monitor the memory consumption, you can do so executing transaction code ST02 or via the menu path Tools | Administration | Monitor | Performance | Setup/Buffers.

Monitoring memory areas and their consumption

Monitoring memory areas and their consumption

You will be able to identify all the memory areas explained in the previous section and observe its level of consumption under Current Use. The Max Used indicator shows the largest amount of memory that has been consumed at some point. Each instance in the system has its corresponding memory areas and therefore you will be able to monitor them separately. When the use reaches or has reached at some point approximately 80% of the memory amount shown under In Memory, that is an indication of possible shortages and that area may be enlarged, if sufficient hardware resources are available.

ometimes the workload is very high, which makes it difficult to isolate the cause of this excessive consumption. The root cause is simply that the workload is very high. If resources are sufficient, enlarging the memory areas would very likely solve the problem. Otherwise, redistributing the workload among the available application servers, especially those that are not experiencing excessive resource consumption, would probably work to your advantage.
However, sometimes this excessive memory consumption may be due to a specific program or transaction that demands resources for its execution.

you may be able to isolate the root cause by identifying certain programs that consume large amounts of memory from the Workload Analysis Monitor, in Administrator view, by choosing from the left-hand side of the screen Analysis Views | Memory Use Statistics. This view shows a history of the top memory consuming programs and the breakdown of memory areas that the program needed to run, such as extended memory of heap memory (referred in this monitor as "private memory"). From here, once you know which programs consume a large amount of memory and may represent a performance "hog" for your users, it is best practice to find out the reasons of such resource consumption.

When you identify custom-developed programs, it is convenient to advise your developers to check these programs for tuning potential and a more efficient use of the resources, especially while creating and manipulating internal tables and so on. There is another way to isolate the root cause of this problem. If you are monitoring the current usage of the system and workload, you may observe users in PRIV mode in SM50 or SM66. Your goal would be to find out why these users are in PRIV mode, is it because they are using excessive memory or because the available extended memory is exhausted and they need to reach heap? By using ST02 you can check the amount of extended memory being used. Double-click on Extended Memory line and you will be taken to a detailed analysis of the memory areas and its consumption.

From there, click on Mode List. This view shows the memory consumed by user in that particular instance as shown in Figure. You will be able to identify which users are executing programs that consume a large amount of memory and obtain answers to the questions outlined above. Sometimes, certain programs that are very resource demanding consume so much extended memory that the rest of the users are left with a very small amount to use and they need to go to heap, entering in PRIV mode and leading to the consequences explained before in regards to not releasing the swap space and therefore contributing to further performance problems.

Identifying the users that use excessive memory in an instance

Identifying the users that use excessive memory in an instance

In order to make the best use of the available memory and configure the memory areas properly, you set up the relevant parameters in the instance profile. Setting up the parameter settings for memory management depends very heavily on the amount of physical memory available and in the architecture. A 32-bit architecture has many limitations in the amount of memory that can actually be allocated, whereas a 64-bit architecture does not normally represent a problem and memory areas (as well as buffer sizes) can be generously defined.

Most of the parameters are operating system independent, although some of them are not or a few extra parameter settings must be set for optimal performance. It is best practice to check SAP Notes that contain the most up to date parameter settings for optimal performance. SAP Note 103747 is the central SAP Note to refer to. There are not optimal parameters that magically work for all systems and all platforms and all sizes. Depending on those and other criteria, the optimal parameter settings for your system may differ from another. Testing in a quality system or a copy of production before implementing those settings in production is always a best practice.

The Buffers in a SAP Instance

Each instance that you define in every application server, even if there are more than instance defined in the same application server, has a set of buffers associated. The buffer sizes are defined by parameter settings in the Instance Profile. There are several buffers and they help to access data more rapidly, as well as to execute ABAP programs faster. The Program Buffer (also known as PXA buffer) is one of the most important ones. When ABAP programs are called to be executed, they will be buffered in this storage area. When this buffer is not large enough, buffer swaps (gaps) occur and this fragmentation in the buffer leads to performance problems, since the ABAP programs need to be reloaded over and over again.

Other buffers like the screen buffer, the calendar buffer, the CUA buffer help building the screens in each dialog step rapidly, because they store the "skeleton" of the screens, the calendars used, and the common pushbuttons and icons. The table buffers store tables temporarily and follow certain important rules to be buffered and to be accessed by ABAP programs. It is best practice for developers to be familiar with these rules when creating custom objects and custom programs that access those objects for efficient access. An access to a buffer can be one hundred times faster than an access to the database. Therefore, applying the rules with care can lead to optimal performance.

Table Buffering

There are three types of table buffering:

  • Partial buffering or single-record buffering. When reading a single record (from the database) of a table that has been buffered as a "single record," that one record will be stored in the buffer. Then further accesses will be hits from the buffer.
  • Generic key buffering. Accessing a record for the first time from a table that is buffered with "generic key buffering" with n number of fields will store in the buffer the table region defined by those n key fields. All other accesses to a record that can be found in that region will be a hit in the buffer.
  • Full buffering. When any record from a table with "full buffering" settings is read from the database, the whole table gets loaded in the buffer and further accesses will be found in the buffer. So other accesses to any record in that table can be found in the buffer.

Tables read from the buffer, then, improve performance. However, rules must be taken into consideration when accessing buffered tables. When a table is changed or updated, then the status in the buffer changes to invalid, meaning that the next access will be performed in the database. It must be that way to guarantee that you read the most up to date data. This leads to the following case: in a central system with only one instance, when a table is changed, there seems to be no problem to access the data again from the database and reload that data onto the buffer. However, what if we have several instances and application servers that have the same tables loaded into their respective buffers?

Imagine the following situation: a user logged on instance 1 updates table ABCD that is loaded into its buffer. That will invalidate the status of that table and the next access from a user logged on that instance will have to go to the database to read that data. Meanwhile, a user logged on instance 2 tries to read table ABCD that is also stored in its buffer. That user will read obsolete data.

In order to prevent this situation, these instances perform a mechanism called "buffer synchronization." When a user updates a buffered table, an entry is made in the database table DDLOG. Imagine DDLOG as a communication pipe between instances, like a message board. The instance that updates a buffered table will write a "message" in DDLOG, such that any other instance can read that "Table ABCD has been updated and therefore you may refresh your buffers now." All other instances, every certain tie, will read from this table and will update their buffered table status accordingly.

This buffer refreshing mechanism works by setting two parameters in the instance profile: rdisp/bufreftime = sendon, exeauto and rdisp/bufreftime = xx, where xx is the number of seconds (by default, 60) that makes every instance read from DDLOG. So, basically, "sendon" means "write onto DDLOG" and "exeauto" means "read from DDLOG." You may set rdisp/bufrefmode to "sendoff" in a central system with only one instance, where no buffer synchronization is necessary.

Troubleshooting Table Buffering for Optimal Performance

Now that you know the different table buffering types, we will discuss what tables should be buffered or not, depending on a certain criteria and how developers in particular can take advantage of these settings for efficient and accurate programming techniques. In the technical settings of a table you specify whether a table is allowed to be buffered or not and what buffering type. To do this, execute transaction SE11 and display a table that you want to change the settings of and click on Technical Settings. The menu path to get to this point is Tools | ABAP Workbench | Development | Dictionary. You may also choose to execute SE13 to display the technical settings of a table directly.

There you may choose if buffering is not allowed for that table or if it is and what type of buffering you choose. In general, tables to be buffered are small and not frequently changed tables. By small, count up to a few megabytes in size. By not frequently changed, think rarely changed for best results. Customizing tables in a production environment do not change very often and are candidates to be buffered. Depending on your hardware resources (memory), you may be able to store more or larger tables in your buffers, if these are bigger. On the other hand, tables that are large or frequently changed should not be buffered. These include normally master data tables and transactional data, for example.

The buffering type you choose for a table will also depend on the size and the type of accesses to that table. Developers know what their programs do and how they decide to access the tables that the use in their programs. Therefore, it is best practice to consider different table buffering types depending on the type of access to the data. For example, a program that accesses in a loop several single records of a table that is relatively big may have that table as a candidate to buffer that table as a single record instead of a full record.

You may also be troubleshooting a program or transaction with a SQL Trace and find similar statements in the trace and it would lead you to the same conclusion. Another example would be to buffer a table choosing Generic Key buffering when using that table in a program that is going to use a certain company code or when you know that in a certain selection screen the user may choose from a very specific set of fields that are key in that table and having that region buffered would improve performance. You may also skip the access to a table that is buffered in an ABAP program by choosing certain commands, such as SELECT (...) BYPASSING BUFFER. The clause BYPASSING BUFFER explicitly ignores the buffer contents and retrieves data from the database, no matter what type of buffering is chosen for that table.

A SELECT statement that does not include the clause SINGLE in its definition bypasses a "single record" buffered table. And in a "generic key" buffered table, if you do not specify all the keys, you bypass the access from the buffer as well. A developer may choose to do this consciously, since in a program, at a certain point, the most up to date data may be needed and therefore, an access to the buffer must be bypassed. Applying the simple rules from above when choosing to buffer or not to buffer a table and programming efficiently using the proper commands can help to improve performance.

You can monitor the access to the tables via transaction ST10 or by the menu path Tools | Administration | Monitor | Performance | Setup/Buffers | Table Calls | Calls. Choose the tables to be analyzed from the selection screen, all tables, certain tables buffered in a certain, buffering type, and choose a period of time and a specific instance or all servers.

Displaying tables in the Table Call Statistics Monitor

Identifying the users that use excessive memory in an instance

The list displayed will show you in detail "table call statistics." So you will be able to see the number of calls passed from an ABAP program to the buffers and the database, the status of a table in the buffer, the size of the object buffered, the number of rows or records affected when a table is loaded onto the buffer, and the number of invalidations. The number of invalidations is especially important to check when a table is buffered and this number is high, because it is an indicator that such table may be a candidate to unbuffer or at least check what possibilities there are to avoid such overhead in the buffer.

On the other hand, when a table is very frequently accessed according to the number of "rows affected" from that monitor and it is not buffered, if it follows certain rules, like the small size and not frequently updated, it may be a possible candidate to buffer. Again, it is important to check and test in quality systems or copies of production before changing these settings in a production environment.

Monitoring SAP Buffers

In order to control the size of the buffers in any SAP system, parameter settings in the instance profile can be set. When the buffers are sized too small for the workload and objects (programs and tables) start to be swapped out of the buffers, you can display "swaps" in these buffers in ST02 (the buffer and memory monitor). You can see the swaps as the number of objects displaced from a buffer. This indicator turns red in the buffer monitor (ST02) when the counter reaches even 1! You can see the free space in the buffer as well by double-clicking on a particular buffer in the buffer monitor to see the detailed statistics as shown in Figure

The statistics shown for table buffers differ slightly from the program buffer, but they have the same general meaning. When displaying the table buffers, the easiest indicator to see that the buffer is full and objects are being swapped is the free space, which could go down to 0.

Detailed statistics of the Program Buffer showing the efficiency of the buffer utilization

Detailed statistics of the Program Buffer showing the efficiency of the buffer utilization

The Program Buffer is one of the most important pieces in tuning an instance, because programs are constantly used and loaded to reuse. When objects are displaced from the buffer, gaps may occur. Gaps can be seen as fragmentation, space that is not usable (like "holes" in the buffer). Especially when the number of gaps reaches the "free space" in KB this means that the buffer is not utilized efficiently and that all free space is not usable. The hit ratio will likely decrease and more objects will be swapped. When this happens, it is time to enlarge the buffer to make more room for objects. There are other alternatives, if resources are limited, such as redistribute the workload among all application servers, especially when other servers are more free.

Parameter settings in the instance profile control the table and program buffers' size and can be changed to achieve optimal performance. After any change, the instance must be restarted to obtain the new value. Carefully change these parameter settings, if you are experiencing poor performance and the root cause is the size of the buffers. Always follow SAP recommendations. The best documentation in parameter settings is located in the Online Help and typical values and recommendations are found in SAP Note 103747.


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

SAP BASIS Topics