| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Method R and CPU Time
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_at_slac.stanford.edu
-----Original Message-----
From: Daniel Fink [mailto:Daniel.Fink_at_Sun.COM]
Sent: Thursday, July 01, 2004 2:00 PM
To: oracle-l_at_freelists.org
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_at_slac.stanford.edu
>
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request_at_freelists.org put
> 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://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_at_freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------Received on Thu Jul 01 2004 - 18:23:49 CDT
 |
 |