Apart from expensive SQL statements, the most important causes of performance problems are internal tables that have many entries. These tables with many entries lead to large requirements for memory and CPU during copy, sort, or search operations on internal tables.
The ABAP debugger enables you to display a list of all internal tables built by a particular program. The ABAP debugger is actually a tool for performing functional troubleshooting of programs. Detailed descriptions of the debugger may be found in SAP literature on ABAP programming. Performance analysis using the ABAP debugger is not a standard procedure and is best performed by an ABAP developer.
Warning: When working with the ABAP debugger, the ABAP program being debugged may terminate and display the error message Invalid interruption of a database selection, or the R/3 System may automatically trigger a database commit. In both cases, an SAP logical unit of work (LUW) has been interrupted, which may lead to inconsistencies in the application tables. Therefore, you should debug only on a test system or in the presence of someone who is very familiar with the program being analyzed and who can manually correct the inconsistencies in the database tables if necessary. See “Debugging Programs in the Production Client” in R/3 Online Documentation for the ABAP debugger.
1. Begin performance analysis with the debugger by starting the program to be analyzed. Then open a second session where you can monitor the program to be analyzed in the Work Process Overview (Transaction code SM50). Enter the debugger from the Work Process Overview by choosing Debugging.
• By using the debugger several times in succession, you can identify the parts of the program that cause a large CPU consumption. Often, these sections consist of LOOP … ENDLOOP statements affecting large internal tables.
2. In the debugger, to display the current memory requirements, from the menu, choose Goto Other screens Memory use.
• Check for cases of unnecessary memory consumption that may have been caused by a nonoptimal program or nonoptimal use of a program. As a guideline value, bear in mind that a program being used by several users in dialog mode should not allocate more than 100MB. Background programs (for example, billing runs at night on a dedicated application server) should not require more than 1GB. With the current 32-bit architecture, program termination typically results when from
1GB•3GB of memory are required.
3. In the debugger, to display a list of the internal tables of the program, first choose Goto System System areas. Then, in the Area field, enter ITAB. In the resulting display, the FILL column shows the number of rows in the respective table. To calculate the memory requirements for the listed tables, multiply the number of rows (indicated in the FILL column) by the width of the header line (indicated in the LENG column).
Experience shows that there are two common programming errors that cause large memory or CPU requirements for programs:
• Missing REFRESH or FREE statements: The ABAP statements REFRESH and FREE delete internal tables and release the memory that was allocated to them. If these statements are not used, memory resources may be unnecessarily tied up.
• Reading in internal tables: The ABAP statement READ TABLE…WITH KEY… allows searching in internal tables. If you use this statement by itself for a standard table, the search is sequential, which is a time-consuming process for large tables. You can significantly improve search performance by adding the statements …BINARY SEARCH (thus specifying a binary search) and SORT TABLE (to sort the table). (See also the F1 Help for ABAP on the statement READ TABLE.)
Note:As of R/3 Release 4.0, you can optimize the performance of operations on large tables by using sorted tables (through the SORTED TABLE statement) or hash tables (through the HASHED TABLE statement).
See also R/3 Online Documentation on the ABAP programming environment.
Summary
R/3 provides numerous tools for a detailed performance analysis of individual ABAP programs.
Analyzing single statistics records lets you narrow down the causes of the performance problems of individual programs to one of the following problem areas:
•
Inefficient table buffering
•
Expensive SQL statements
•
High CPU consumption
The SQL trace is the tool to use for analyzing expensive SQL statements in ABAP programs. Evaluating the trace enables you to identify throughput bottlenecks in the database or due to network problems.
For problems of high CPU consumption, use the ABAP trace. In contrast to the SQL trace, this enables time measurements for operations on internal tables such as LOOP, READ, and SORT. Alternatively, CPU-consuming programs can be monitored through the ABAP debugger from the Work Process Overview. This form of analysis should be performed only by ABAP developers.
Figure 4.5 summarizes the procedure for analyzing a single program or transaction.
Figure 4.5: Performance analysis procedure for an ABAP program
Review Questions
1.
What do you have to consider when you perform an SQL trace?
A.There is only one trace file in each R/3 System. Therefore, only one SQL trace can be performed at a time.
B.The user whose actions are being traced should not run multiple programs concurrently.
C.You should perform the SQL trace on a second execution of a program because the relevant buffers are then already loaded.
D.SQL traces are useful on the database server, but not on application servers, which yield inexact results due to network times.
2.
When should you perform an ABAP trace?
A.
If a problem occurs with the table buffer
B.
For programs with high CPU requirements
C.For I/O problems with hard disks
Chapter 5: Configuring R/3 Memory Areas
Overview
This chapter helps you optimize the configuration of the R/3 memory areas for each R/3 instance: R/3 buffers, R/3 roll memory, R/3 extended memory, R/3 paging memory, R/3 heap memory (variable local memory for R/3 work processes), and fixed local memory for R/3 work processes.
The first part of the chapter explains the function of each memory area and its effect on R/3 System performance. The second part explains how to optimally configure these memory areas for different operating systems and provides concrete configuration recommendations.
The decisive factors affecting memory configuration are as follows:
• Physical memory (RAM): The amount of physically available main memory should be proportionate to the amount of virtually allocated memory. Ask yourself which memory areas within physical memory are the most urgently required at times of high system load.
• Limits of the operating system: Is the desired size of particular memory areas too large for a given type of operating system?
When Should You Read This Chapter?
Read this chapter if you wish to configure R/3 memory areas in a new installation; after an upgrade or extension to your R/3 System; or if you have detected performance problems related to memory area configuration.