Received: from localhost (maia-4.hub.org [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 0E6829FB303 for ; Fri, 27 Apr 2007 06:53:51 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 85163-03 for ; Fri, 27 Apr 2007 06:53:47 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from ipmail02.adl2.internode.on.net (ipmail02.adl2.internode.on.net [203.16.214.141]) by postgresql.org (Postfix) with ESMTP id 519819FB2FF for ; Fri, 27 Apr 2007 06:53:46 -0300 (ADT) X-IronPort-AV: E=Sophos;i="4.14,460,1170595800"; d="scan'208";a="116113931" Received: from ppp247-71.static.internode.on.net (HELO [192.168.8.200]) ([203.122.247.71]) by ipmail02.adl2.internode.on.net with ESMTP; 27 Apr 2007 19:23:44 +0930 Message-ID: <4631C825.9000705@Sheeky.Biz> Date: Fri, 27 Apr 2007 19:23:41 +0930 From: Shane Ambler User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Magnus Hagander CC: Andres Retzlaff , pgsql-performance@postgresql.org Subject: Re: Usage up to 50% CPU References: <20070427080653.GB12895@svr2.hagander.net> <20070427081350.GD12895@svr2.hagander.net> In-Reply-To: <20070427081350.GD12895@svr2.hagander.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.643 tagged_above=0 required=5 tests=AWL=1.229, BAYES_00=-2.599, BIZ_TLD=2.013 X-Spam-Level: X-Archive-Number: 200704/462 X-Sequence-Number: 24339 Magnus Hagander wrote: > On Fri, Apr 27, 2007 at 08:10:48AM +0000, Andres Retzlaff wrote: >> Hi Magnus, >> >> in this case each CPU goes up to 50%, giveing me 50% total usage. I was >> specting as you say 1 query 100% cpu. >> >> Any ideas? > > No. 1 query will only use 100% of *one* CPU, which means 50% total usage. > You need at least one query per CPU to reach full 100% of the whole system. > (Actually, you can get slightly above 50% since the query will run on one > CPU and the OS and autovacuum and bgwriter can run on the other. But it's > marginally) > > //Magnus I would think that as you are sitting and watching the cpu usage, your query would seem to taking a while to run, leading me to wonder if you are getting a full table scan that is causing pg to wait for disk response? Or are you running a long list of steps that take a while? -- Shane Ambler pgSQL@Sheeky.Biz Get Sheeky @ http://Sheeky.Biz