Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 54CC9B5DBDA for ; Wed, 6 Jul 2011 20:36:55 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 80158-09 for ; Wed, 6 Jul 2011 23:36:49 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from www.postnewspapers.com.au (www.postnewspapers.com.au [173.230.139.50]) by mail.postgresql.org (Postfix) with ESMTP id C63EFB5DBD0 for ; Wed, 6 Jul 2011 20:36:48 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by www.postnewspapers.com.au (Postfix) with ESMTP id CCE1F37; Wed, 6 Jul 2011 19:36:48 -0400 (EDT) X-Virus-Scanned: amavisd-new at postnewspapers.com.au.com Received: from www.postnewspapers.com.au ([127.0.0.1]) by localhost (www.postnewspapers.com.au [127.0.0.1]) (amavisd-new, port 10024) with LMTP id uLeHHLL9rL+Y; Wed, 6 Jul 2011 19:36:48 -0400 (EDT) Received: from mail.postnewspapers.com.au (ppp171-128.static.internode.on.net [150.101.171.128]) by www.postnewspapers.com.au (Postfix) with ESMTP id B931C27; Wed, 6 Jul 2011 19:36:47 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.postnewspapers.com.au (Postfix) with ESMTP id 48823AF353; Thu, 7 Jul 2011 07:36:46 +0800 (WST) X-Amavis-Modified: Mail body modified (using disclaimer) - mail.postnewspapers.com.au X-Virus-Scanned: Debian amavisd-new at postnewspapers.com.au Received: from mail.postnewspapers.com.au ([127.0.0.1]) by localhost (mail.postnewspapers.com.au [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CrkyEIrIbFUV; Thu, 7 Jul 2011 07:36:41 +0800 (WST) Received: from [10.1.1.7] (124-169-57-156.dyn.iinet.net.au [124.169.57.156]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Craig Ringer", Issuer "POST Certificate Authority" (verified OK)) by mail.postnewspapers.com.au (Postfix) with ESMTPSA id 1EB73AF434; Thu, 7 Jul 2011 07:36:41 +0800 (WST) Message-ID: <4E14F186.5020105@postnewspapers.com.au> Date: Thu, 07 Jul 2011 07:36:38 +0800 From: Craig Ringer User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Tomas Vondra CC: pgsql-performance@postgresql.org Subject: Re: 100% CPU Utilization when we run queries. References: <1307506768241-4465765.post@n5.nabble.com> <4DEF037E.9020105@postnewspapers.com.au> <1307691557007-4475458.post@n5.nabble.com> <4DF21007.2010807@postnewspapers.com.au> <1308198900426-4493567.post@n5.nabble.com> <1309959046671-4556775.post@n5.nabble.com> <4E14B1AD.40306@fuzzy.cz> In-Reply-To: <4E14B1AD.40306@fuzzy.cz> 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=-1.91 tagged_above=-10 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201107/27 X-Sequence-Number: 44239 On 7/07/2011 3:04 AM, Tomas Vondra wrote: > That is done by sorting the data, and sorting is very CPU intensive task > usually. So the fact that the CPU is 100% utilized is kind of expected > in this case. So that's a feature, not a bug. > > In general each process is hitting some bottleneck. It might be an I/O, > it might be a CPU, it might be something less visible (memory bandwidth > or something like that). > This is worth stressing. PostgreSQL will always use as much CPU time and disk I/O as it can to get a job done as quickly as possible. Because most queries need more CPU and less disk, or more disk and less CPU, you'll usually find that PostgreSQL maxes out one or the other but not both. People monitor CPU use more than disk use, so they tend to notice when CPU use is maxed out, but Pg maxes out your disk a lot too. This is normal, and a good thing. If Pg didn't max out your CPU or disk, queries would be slower. If you want to make things other than PostgreSQL happen faster at the expense of slowing down queries, you can use your operating system's process priority mechanisms to give PostgreSQL a lower priority for access to CPU and/or disk. That will still allow PostgreSQL to use all your CPU and disk when nothing else wants it, but will let other programs use it in preference to PostgreSQL if they need it. The same thing applies to memory use. People notice that their operating system reports very little "free" memory and get worried about it. The truth is that your OS should never have much free memory, because that memory is not being used for anything useful. It usually keeps disk cache in memory when it's not needed for anything else, and trying to make more "free" memory clears out the disk cache, making the computer slower. CPU use is a bit like that - it's not doing any good idle, so if nothing else needs it more you might as well use it. If you're on linux, you can use the "nice", "renice" and "ionice" programs to control CPU and disk access priority. -- Craig Ringer POST Newspapers 276 Onslow Rd, Shenton Park Ph: 08 9381 3088 Fax: 08 9388 2258 ABN: 50 008 917 717 http://www.postnewspapers.com.au/