Re: Same operation, more CPU time

From: Jonathan Lewis <jonathan_at_jlcomp.demon.co.uk>
Date: Wed, 5 May 2004 23:07:15 +0100
Message-ID: <001001c432ed$56b9c670$7102a8c0@Primary>

I think if you had to do more work in creating read consistent blocks, the trace file would show the access to the undo blocks as part of the "query" column, which you would have noticed.

If you are busy updating, then perhaps you have extra competition for latches, so you may be expending extra CPU spinning for latches, and being pushed off the run queue etc. Whilst the apparent difference in time might then seem unreasonable for the likely effects, it is possible that the actual difference in time is small, but the increment is enough to allow what Cary calls
(something like) "quantization" errors to become
exaggerated.

You may also have effects like processes yielding, but staying runnable when not competing, whereas they may have to sleep when competing - and this could affect the CPU - please note that I am hand-waving and mumbling when I say this.

Regards

Jonathan Lewis

http://www.jlcomp.demon.co.uk

http://www.jlcomp.demon.co.uk/faq/ind_faq.html The Co-operative Oracle Users' FAQ

http://www.jlcomp.demon.co.uk/seminar.html Optimising Oracle Seminar - schedule updated May 1st

Original Message ----- From: "Paul Baumgartel" <treegarden_at_yahoo.com> To: <oracle-l_at_freelists.org> Sent: Wednesday, May 05, 2004 4:39 PM Subject: Same operation, more CPU time

Hi all.

I'm doing some performance testing--the purpose is to see how the response time of our interactive Web application changes when a batch-mode data load process runs concurrently.

The response time of the GUI does increase. A 10046 trace does not show significant additional wait events that account for the extra time--instead, it appears that CPU usage for the same operations increases. For example, in the GUI test with nothing else running, a particular query might take .03 seconds of CPU per row; with the data load running, the same query might take .055 seconds. The optimizer plan lines in the tkprof output show greater CPU time for each step
(e.g., block gets via rowid, hash join, etc.). I emphasize that the
difference is in CPU consumption, not just elapsed time--again, there is no significant different in wait time between the two executions. Also, the database server's overall CPU usage never exceeded 46% during the tests.

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 Wed May 05 2004 - 17:04:26 CDT