| 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: cpu average load
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
> 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_at_freelists.org =
> [mailto:oracle-l-bounce_at_freelists.org]
> On Behalf Of Gogala, Mladen
> Sent: Tuesday, November 30, 2004 9:19 AM
> To: 'cary.millsap_at_hotsos.com';
> oracle-l_at_freelists.org
> 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_at_hotsos.com]=20
> Sent: Tuesday, November 30, 2004 9:59 AM
> To: oracle-l_at_freelists.org
> 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.
>
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
> --
> http://www.freelists.org/webpage/oracle-l
>
-- http://www.freelists.org/webpage/oracle-lReceived on Wed Dec 01 2004 - 03:38:24 CST
 |
 |