Performance of a system is often intriguing and perplexing. It helps to understand the nuances that go in letting a system perform the way it does. CPU Time and processing time are important factors that affect the system performance; here is a deep dive into these aspects.
CPU time is the amount of time for which a Central Processing Unit (CPU) was used for processing instruction of a computer program or operating system. The CPU time is measured in seconds or clock ticks. Often, it is useful to measure CPU time as a percentage of the CPU’s capacity, which is called the CPU usage.
CPU time and CPU usage have two main uses. The first use is to quantify the overall busyness of the system. In general when the CPU usage is above 70%, the user may experience lag. Such high CPU usage indicates insufficient processing power. Either the CPU needs to be upgraded, or the user experience reduced, for example, by switching to lower resolution graphics or reducing animations.
The second use, with the advent of multi-tasking, is to quantify how the processor is shared between computer programs. A high CPU usage of a single program may indicate that it is highly demanding on processing power or that it may malfunction, for example, it has entered an infinite loop. CPU time allows to measure how much processing power a single program requires, eliminating interference, such as time executed waiting for input or being suspended to allow other programs to run. In contrast, elapsed real time (or simply real time) is the time taken from the start of a computer program until the end as measured by an ordinary clock. Elapsed real time includes I/O time and all other types of waits incurred by the program.
Element that will affect CPU time in SAP R/3 System:
- Roll in time is time taken by the Operating system to move the user context from the roll area to the local memory of work process
- Rolling out is the time taken to saves the current user context data to the virtual memory at the conclusion of a transaction step
- Load time and Generation time is the time taken to load all ABAP programs and screens that are required and are not yet available in the application server buffers
- Database CPU time is the time taken when data is read or changed in the database, it is measured from the moment of sending the database request to the database server and runs until the moment at which the data is returned to the application server
- ABAP processing time is the time taken to run the ABAP programs that are required for the business process in the application server
- Data base Input / output activity will use more CPU time
CPU time is not determined by the operating system. CPU time is not an additive component of transaction response time but is consumed during load time, roll time, and processing time see below figure to understand response time and its components
The programs are processed during processing time and as a result, CPU capacity is normally “consumed” during this time. As a result, processing time and CPU time should be more or less the same. As a rule of thumb, the difference between processing time and CPU time should not be more than 100%. Greater “lost times” indicate performance problems.
Possible causes for a significant difference between processing time and CPU time?
_ The first possible cause is a CPU bottleneck. This would mean there is not enough CPU capacity available for the SAP work processes, which must therefore wait until CPU becomes available. In this case, processing time is being measured in the work process while no CPU time is used, and this processing time is considerably larger than CPU time.
_ Another reason for a difference between processing time and CPU time concerns wait times in the SAP work process. Whenever the SAP work process has a status “stopped”, processing time is measured without CPU time being used. This type of wait situation can be identified in the Work Process Overview.
The two possible causes of a CPU bottleneck are as follows:
Poor load distribution:
The load is not optimally distributed across the servers. There may be servers with free CPU or main memory capacity. Alternatively, load distribution may become nonoptimal at certain times of the day, for example, when several background processes are run in parallel during periods of peak system load. You should be able to reschedule these programs to run at times of low system load.
Individual processes causing a high CPU load:
Individual processes with a high CPU load may be running at times of high system load. Such processes may include database processes (with expensive SQL statements, high I/O rate), SAP work processes (with programs running as background jobs), or processes external to SAP. To improve performance, you may be able to tune, reschedule, or (in the case of external processes) cancel these processes.
Tool and Analysis
System Analysis Trace (SAT) / Runtime Analysis is the tool that will be widely used to analyze the high CPU times
I. SAT is the new version of SE30 and it provides the ABAP trace with the below information
· Monitors runtime on application servers on the basis of events
· Displays information such as the number of executions, gross and net CPU times
· Shows call hierarchy, i.e. the processing sequence
II. Structure of ABAP Trace
III. Steps to analyze the results:
a) Overview: Check total times and ratios (ABAP : SQL : System)
b) Hit list: What is executed and how long does it take?
c) Call hierarchy: What is the order of execution?
d) Table hit list: Which tables are accessed (buffer and DB)
e) Other hit lists: Special purposes
f) View ABAP source to find the reason for problematic lines of code
IV. Steps to be followed if CPU Time is found to be high
- Identify the top contributing methods in terms of net time should be considered.
- Right click on the method name and click on Position in the hierarchy tool to look into the hit list.