Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 8BA1E1337C60 for ; Sun, 6 Feb 2011 23:05:16 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 63077-02-2 for ; Mon, 7 Feb 2011 03:05:10 +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 61A1C1337C6D for ; Sun, 6 Feb 2011 23:03:41 -0400 (AST) Received: from localhost (localhost [127.0.0.1]) by www.postnewspapers.com.au (Postfix) with ESMTP id 2084C881; Sun, 6 Feb 2011 22:03:41 -0500 (EST) 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 E9n3OQRnT1hK; Sun, 6 Feb 2011 22:03:39 -0500 (EST) 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 3900D19; Sun, 6 Feb 2011 22:03:39 -0500 (EST) Received: from [10.0.0.53] (wallace.localnet [10.0.0.53]) by mail.postnewspapers.com.au (Postfix) with ESMTP id 38E52AEB50; Mon, 7 Feb 2011 11:03:38 +0800 (WST) Message-ID: <4D4F6109.1090209@postnewspapers.com.au> Date: Mon, 07 Feb 2011 11:03:37 +0800 From: Craig Ringer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Thunderbird/3.0.4 MIME-Version: 1.0 To: felix CC: "pgsql-performance@postgresql.org" Subject: Re: Really really slow select count(*) References: <4D4C138C.7010304@2ndquadrant.com> <4D4C1555.40209@peak6.com> <4D4C2AC3.5020804@peak6.com> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 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: 201102/276 X-Sequence-Number: 42414 On 07/02/11 09:52, felix wrote: > So is it normal for postgres to report that it failed to shut down, > operate for an hour and then go ahead and restart itself ? That's pretty wacky. Did you shut it down via pg_ctl or using an init script / "service" command in your OS? It shouldn't matter, but it'd be good to know. If the problem is with an init script, then knowing which OS and version you're on would help. If it was with psql directly, that's something that can be looked into. > this was changing one configuration parameter. something I was advised > to do, read about quite a bit, tested on my development server (mac) and > then proceeded to do at 6 am on Sunday morning, our slowest time. System V shared memory is awful - but it's really the only reasonable alternative for a multi-process (rather than multi-threaded) server. PostgreSQL could use mmap()ed temp files, but that'd add additional overheads and they'd potentially get flushed from main memory unless the memory was mlock()ed. As mlock() has similar limits and configuration methods to system V shared memory, you get back to the same problem in a slightly different form. What would possibly help would be if Pg could fall back to lower shared_buffers automatically, screaming about it in the logs but still launching. OTOH, many people don't check the logs, so they'd think their new setting had taken effect and it hadn't - you've traded one usability problem for another. Even if Pg issued WARNING messages to each client that connected, lots of (non-psql) clients don't display them, so many users would never know. Do you have a suggestion about how to do this better? The current approach is known to be rather unlovely, but nobody's come up with a better one that works reasonably and doesn't trample on other System V shared memory users that may exist on the system. > so does the above mean that I don't have to restart the entire server, > just postgres ? I assumed that changing kernel settings means rebooting > the server. Nope. sysctl settings like shmmax may be changed on the fly. -- System & Network Administrator POST Newspapers