Section 7.6. CPU Consumption Double-Counting

   

7.6 CPU Consumption Double-Counting

Another inaccuracy in the relationship:

figs/eq_0702.gif

is an inherent double-counting of CPU time in the right-hand side of the approximation . The Oracle kernel definition of the c statistic is all time spent in user running and kernel running states. Each ela statistic contains all time spent within an instrumented sequence of Oracle kernel instructions. When the instrumented sequence of instructions causes consumption of CPU capacity, that consumption is double-counted.

For example, imagine an Oracle database call that performs a disk read, such as the one shown in Figure 7-4. In this drawing, a database call begins its execution at time e . For the duration labeled A , the call consumes CPU capacity in the user running state. At time ela , the Oracle kernel process issues the gettimeofday call that precedes the execution of an Oracle wait event. Depending upon the operating system, the execution of the gettimeofday system call puts the Oracle kernel process into kernel running state for a few microseconds before retuning the process to user running state.

Some Linux kernels allow the gettimeofday system call to execute entirely in user running state, resulting in a significant performance improvement (for one example, see http://www-124.ibm.com/linux/patches/?patch_id=597).

After some more CPU consumption in user running state for the duration labeled B , the process transitions into kernel running state for the duration labeled C . At the conclusion of duration C , the kernel process transitions to the asleep state and awaits the result of the request from the disk.

Figure 7-4. This Oracle database call consumes CPU in both user mode and kernel mode, and it waits for a read from disk
figs/oop_0704.gif

Upon completion of the request, the disk sends an interrupt that motivates the wakeup of the Oracle kernel process, which then transitions to the ready to run state. In Figure 7-4, the CPU is idle at this point in time, and the process is immediately scheduled and thus transitioned to kernel running state. While executing in this state, the Oracle process then wraps up the details of the disk I/O call, such as the copying of the data from the I/O channel to the Oracle process's user-addressable memory, which consumes the duration labeled D .

Finally at the end of duration D , the disk read call returns, and the Oracle process transitions to user running state for the duration labeled E . At time ela 1 , the Oracle process marks the end of the disk read with a gettimeofday call. The Oracle process then proceeds to execute the remaining instructions (also in user running state) that are required to complete the database call. Finally, at time e 1 , the database call processing is complete.

As the result of these actions, the Oracle kernel will produce the following statistics for the database call:

e = e 1 - e
ela = ela 1 - ela = B + C + Disk + D + E
c = A + B + C + D + E + F

I shall describe, a little later, exactly how c is computed. The value that c will have is approximately the sum of the durations A , B , C , D , E , and F . At this point, it should be easy for you to see where the double-counting occurs. Both ela and c contain the durations B , C , D , and E . The segments of CPU consumption that have occurred within the confines of the wait event have been double-counted.

How big of a problem is the double-counting? Fortunately, the practical impact is usually negligible. Our experience with over a thousand trace files at www.hotsos.com indicates that the durations marked as B , C , D , and E in Figure 7-4 are usually small. It appears that most of the wait events instrumented in Oracle8 i and Oracle9 i have response times (that is, ela values) that are dominated by durations other than CPU consumption. In a few rare cases (I'll show you one shortly), the double-counting shows up in small sections of trace data, but in the overall scheme of Oracle response time accounting, the effect of CPU consumption double-counting seems to be generally negligible.


   
Top


Optimizing Oracle Performance
Optimizing Oracle Performance
ISBN: 059600527X
EAN: 2147483647
Year: 2002
Pages: 102

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net