From oracle-l-bounce@freelists.org Wed May 5 17:04:26 2004 Return-Path: Received: from air189.startdedicated.com (root@localhost) by orafaq.com (8.11.6/8.11.6) with ESMTP id i45M4BO21430 for ; Wed, 5 May 2004 17:04:21 -0500 X-ClientAddr: 206.53.239.180 Received: from turing.freelists.org (freelists-180.iquest.net [206.53.239.180]) by air189.startdedicated.com (8.11.6/8.11.6) with ESMTP id i45M40621398 for ; Wed, 5 May 2004 17:04:10 -0500 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 2ADF172C976; Wed, 5 May 2004 16:54:53 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24312-57; Wed, 5 May 2004 16:54:53 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 649B072D526; Wed, 5 May 2004 16:54:52 -0500 (EST) Received: with ECARTIS (v1.0.0; list oracle-l); Wed, 05 May 2004 16:53:37 -0500 (EST) X-Original-To: oracle-l@freelists.org Delivered-To: oracle-l@freelists.org Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id BF1D772DB0C for ; Wed, 5 May 2004 16:53:29 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24312-39 for ; Wed, 5 May 2004 16:53:29 -0500 (EST) Received: from hafnium.btinternet.com (hafnium.btinternet.com [194.73.73.121]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 692F972DA07 for ; Wed, 5 May 2004 16:53:29 -0500 (EST) Received: from [217.43.69.170] (helo=Primary) by hafnium.btinternet.com with smtp (Exim 3.22 #25) id 1BLUXw-00046j-00 for oracle-l@freelists.org; Wed, 05 May 2004 23:07:20 +0100 Message-ID: <001001c432ed$56b9c670$7102a8c0@Primary> From: "Jonathan Lewis" To: References: <20040505153940.79734.qmail@web13426.mail.yahoo.com> Subject: Re: Same operation, more CPU time Date: Wed, 5 May 2004 23:07:15 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Virus-Scanned: by amavisd-new at freelists.org X-archive-position: 4527 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-To: oracle-l-bounce@freelists.org X-original-sender: jonathan@jlcomp.demon.co.uk Precedence: normal Reply-To: oracle-l@freelists.org X-list: oracle-l X-Virus-Scanned: by amavisd-new at freelists.org 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" To: 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@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 -----------------------------------------------------------------