RE: Method R and CPU Time
- From: "MacGregor, Ian A." <ian@xxxxxxxxxxxxxxxxx>
- To: "'oracle-l@xxxxxxxxxxxxx'" <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 1 Jul 2004 16:26:45 -0700
This is one statement with four different wait events. Actually there were
other wait events such as "SQL*net message to client, but their totals were
less than a centisecond. That's why the CPU_SPECS and the elapsed_secs are the
same throughout. They are what was calculated for the sql statement not for
the wait event.
To throw another wrinkle into this it is actually the same statement with
different bind variables run 10 times in successionby a single session. The
statement is looking at signals from a klystron being developed to power the
Next Linear Collider. Sometimes the physicists want to see output of a single
signal over a twenty-four hour period and sometimes they want to pull a
basketful. This statement is looking at response times for a commonly
requested "basket".
Ian MacGregor
Stanford linear Accelerator Center
ian@xxxxxxxxxxxxxxxxx
-----Original Message-----
From: Daniel Fink [mailto:Daniel.Fink@xxxxxxx]
Sent: Thursday, July 01, 2004 2:00 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: Method R and CPU Time
Ian,
I know this does not answer your question, but the fact that each event had the
*exact* same CPU_SECs strikes me as odd. Are you sure this
calculation/retrieval is correct?
As for CPU_SECS + WAIT_SECS = ELA_SECS, CPU is only incremented when the
process is on the CPU and the CPU clock increments. It is theoretically
possible that you could accumulate 0 cpu_seconds because the process was never
on the CPU when the clock ticked. You could also have CPU seconds in the PARSE,
EXEC and FETCH calls that may not be accounted for here.
Regards,
Daniel Fink
"MacGregor, Ian A." wrote:
> I'm having a hard time determining how much time is actually spent on
> CPU,
>
> Consider the following
> Runtime TRACE_ID EVENT WAITS
> WAIT_SECS ELAPSED_SECS CPU_SECS
> 25-JUN-2004 12:05 nlco_ora_7279 db file sequential read 96
> .27 14.29 13.07
> 25-JUN-2004 12:05 db file scattered read 378
> 7.14 14.29 13.07
> 25-JUN-2004 12:05 SQL*Net message from client 475
> 1.34 14.29 13.07
> *************************** -----
> -----
> sum 949
> 8.75
>
> The CPU_SECS + WAIT_SECS should equal elapsed secs at least approximately. I
> know there is some double counting between the file i/o waits and the CPU's
> but 13.07 + 8.75 = 21.82 and 21.82/14.29 * 100 = anout 153%. That's a lot
> more than the incidental double-counting error Cary speaks of in his book.
>
> This particular machine has 4 CPU's and when looking at CPU usage at the
> system level one needs to take that into account. But what about for
> individual statements that are not parallelized; i.e., running against one
> and only one CPU, does one need to divide the CPU results by four on a four
> CPU machine.
>
> Ian MacGregor
> Stanford Linear Accelerator Center
> iam@xxxxxxxxxxxxxxxxx
>
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put
> 'unsubscribe' in the subject line.
> --
> Archives are at //www.freelists.org/archives/oracle-l/
> FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe'
in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
