RE: cpu average load
- From: Martic Zoran <zoran_martic@xxxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Wed, 1 Dec 2004 01:41:48 -0800 (PST)
The one way is always tracing.
I beleive Cary explained every case in his book.
But nor sure that you want to read or parse every line
of your 10046 trace. I will always opt to pay a few
bucks to some parser on the net.
But, not sure that it is not possible to be covered
differently with timed_os_statistics parameter that is
giving you at least some OS timing statistics from v$
views.
Is that reliable?
Did anybody was playing with this apart from me?
Any bad (wrong) behaviour with using OS statistics
with timed_os_statistics?
If not reliable in 9i is it in 10g?
Anybody?
Are we refusing Oracle OS statistics here as non
reliable or I missed some article/paper/doc (very
possible if you imagine how huge is Oracle community)?
At the end turning timed_os_statistics for some
session or the db is probably not crazy overhead, or
at least not bigger then level 8 tracing.
Regards,
Zoran
--- Cary Millsap <cary.millsap@xxxxxxxxxx> wrote:
> I disagree that this advice is difficult to
> implement in practice, =
> because I
> implement it in practice frequently. Optimizing
> Oracle Performance =
> pp170-173
> illustrates a very simple case that applies nicely
> to much more =
> complicated
> Oracle cases. Ironically, I helped diagnose another
> real-life case of =
> this
> type just 15 minutes ago.
>
> The Oracle c statistic includes both the utime and
> stime components of =
> the
> getrusage return value. (You can *prove* that by
> intercepting your =
> getrusage
> calls and manipulating their return data.)
> Therefore, the "e" time =
> that's
> not accounted for by any "c" (usr mode CPU plus sys
> mode CPU consumed by =
> the
> Oracle kernel) time or "ela" time (mostly time spent
> asleep awaiting a
> syscall return) is going to be a reasonably reliable
> measure (+/-10%) of
> time spent preempted.
>
> What helps my confidence significantly is that over
> and over again, I =
> see
> that unaccounted-for time computed in the manner
> I've described reliably
> measures the amount of time that a process spends
> preempted.
>
> It works. Really.
> =20
>
> Cary Millsap
> Hotsos Enterprises, Ltd.
> http://www.hotsos.com
> * Nullius in verba *
>
> Upcoming events:
> - Performance Diagnosis 101: 1/4 Calgary
> - SQL Optimization 101: 12/13 Atlanta
> - Hotsos Symposium 2005: March 6-10 Dallas
> - Visit www.hotsos.com for schedule details...
>
>
> -----Original Message-----
> From: oracle-l-bounce@xxxxxxxxxxxxx =
> [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
> On Behalf Of Gogala, Mladen
> Sent: Tuesday, November 30, 2004 9:19 AM
> To: 'cary.millsap@xxxxxxxxxx';
> oracle-l@xxxxxxxxxxxxx
> Subject: RE: cpu average load
>
> This was a very precise and correct answer, but
> unfortunately rather =
> hard to
> Implement in practice. Process preemption or context
> switching, as it is
> sometimes called, happens while CPU is in kernel
> mode. Kernel mode is
> normally spent only on 2 major things:=20
> 1) context switching
> 2) paging
> CPU being in kernel mode means that OS it taking
> care of its own health =
> and
> Happiness and not working on the user request.
> Commands like ps -lp =
> <PID> or
> top will give you precise amount of kernel mode
> spent by your process. =
> If
> that amount is significant, it warrants further
> investigation by using =
> truss
> or strace. BTW, whenever a system service is
> requested, a context change
> happens. It includes things like read, write, stat
> and alike. The =
> mechanism=20
> for calling system services is based on "switch mode
> to kernel" trap. =
> System
> service number is the 1st argument for the trap
> handler.
>
> --
> Mladen Gogala
> Ext. 121
>
> -----Original Message-----
> From: Cary Millsap
> [mailto:cary.millsap@xxxxxxxxxx]=20
> Sent: Tuesday, November 30, 2004 9:59 AM
> To: oracle-l@xxxxxxxxxxxxx
> Subject: RE: cpu average load
>
> The amount of response time that process preemptions
> are costing your
> performance is measured as the amount of response
> time in an extended =
> SQL
> trace file that is not accounted for by the sum of
> your file's c values =
> at
> recursive depth zero, plus the sum of your file's
> ela values.
>
>
>
> --
> //www.freelists.org/webpage/oracle-l
>
> --
> //www.freelists.org/webpage/oracle-l
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
//www.freelists.org/webpage/oracle-l
Other related posts:
