Cary, thanks a lot for the explanation (and the other
one [and especially the other one :-) ]). Much
appreciated.
--- Cary Millsap [EMAIL PROTECTED] wrote:
You're on the right trail by experimenting with it.
I'm surprised that
the number of gettimeofday() calls is so small. The
times() call
Wolfgang,
The OS has always provided microsecond data to the Oracle kernel (see
the 'man gettimeofday' and 'man getrusage'). It's only in release 9 that
the Oracle kernel stopped truncating the data at the centisecond digit
(by doing an integer division of 1).
Oracle gets elapsed times by
Thanks for the clarification.
At 10:29 AM 12/3/2003, you wrote:
Wolfgang,
The OS has always provided microsecond data to the Oracle kernel (see
the 'man gettimeofday' and 'man getrusage'). It's only in release 9 that
the Oracle kernel stopped truncating the data at the centisecond digit
(by
Litchfield
Sent: 02 December 2003 22:24
To: Multiple recipients of list ORACLE-L
Subject: RE: raw traces - EXEC: c=10,000 e=40
I'd be highly, highly suspicious of the cpu time
c.
1. You should be able to verify (roughly the
elapsed time) of
the statement, if by no other means
will be
limited by the accuracy of gettimeofday.
Niall
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Niall Litchfield
Sent: 02 December 2003 22:24
To: Multiple recipients of list ORACLE-L
Subject: RE: raw traces - EXEC: c=10,000 e=40
: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Niall Litchfield
Sent: 02 December 2003 22:24
To: Multiple recipients of list ORACLE-L
Subject: RE: raw traces - EXEC: c=10,000 e=40
I'd be highly, highly suspicious of the cpu time
c.
1. You should be able to verify
Reading Cary's book I understand that c and e are
measured via different system calls (haven't truss'ed
[well tusc'ed] them yet - I am on HP-UX 11.11), but
would anybody know what the reasonable upper limit of
c-e might be?
I am looking at the trace file where c is more than
two orders of
Hi!
I haven't read Cary's book yet (although it's already waiting on my
bookshelf), but I think CPU time c is measured in timeslice steps (100ms)
and elapsed time e is taken from system timer or smth like that. Others will
know better :)
Tanel.
- Original Message -
To: Multiple
In Oracle 9, Oracle tries to measure times in microseconds (as opposed to
centiseconds pre-9). However, many Systems only slice time far coarser than
that so Oracle has to fake it to some degree and that faking may be
different between cpu time and elapsed time. Take your cpu times for
On your platform, c is measured in centiseconds (10,000 microseconds)
whilst e has a notional accuracy to the microsecond. So the extremes
are to be expected.
Regards
Jonathan Lewis
http://www.jlcomp.demon.co.uk
The educated person is not the person
who can answer the questions, but the
: raw traces - EXEC: c=10,000 e=40
Reading Cary's book I understand that c and e are
measured via different system calls (haven't truss'ed
[well tusc'ed] them yet - I am on HP-UX 11.11), but
would anybody know what the reasonable upper limit of
c-e might be?
I am looking at the trace file
.
Niall
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Niall Litchfield
Sent: 02 December 2003 22:24
To: Multiple recipients of list ORACLE-L
Subject: RE: raw traces - EXEC: c=10,000 e=40
I'd be highly, highly suspicious of the cpu time c.
1
Boris,
Your three cases are a simpler manifestation of the problem described in
Figure 7-8 of Optimizing Oracle Performance (pp163-165).
Each of the three db calls you show happened to be either in the 'kernel
running' or 'user running' OS process state when a scheduler interrupt
occurred. Each
13 matches
Mail list logo