Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id C4EDF632FED for ; Tue, 20 Apr 2010 17:39:31 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 41387-01 for ; Tue, 20 Apr 2010 20:39:21 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from vexbert.mr-paradox.net (vexbert.mr-paradox.net [198.145.180.174]) by mail.postgresql.org (Postfix) with ESMTP id 4D717632F34 for ; Tue, 20 Apr 2010 17:39:21 -0300 (ADT) Received: by vexbert.mr-paradox.net (Postfix, from userid 18391) id E1AA8845D3; Tue, 20 Apr 2010 16:39:19 -0400 (EDT) Date: Tue, 20 Apr 2010 13:39:19 -0700 From: David Kerr To: Greg Smith Cc: Scott Marlowe , Nikolas Everett , Robert Haas , pgsql-performance@postgresql.org Subject: Re: Very high effective_cache_size == worse performance? Message-ID: <20100420203919.GA62103@mr-paradox.net> References: <20100420173936.GA50886@mr-paradox.net> <20100420180351.GA51940@mr-paradox.net> <20100420182030.GA53489@mr-paradox.net> <20100420182832.GB53489@mr-paradox.net> <4BCE0E0C.1020903@2ndquadrant.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BCE0E0C.1020903@2ndquadrant.com> User-Agent: Mutt/1.4.2.3i 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: 201004/266 X-Sequence-Number: 38516 On Tue, Apr 20, 2010 at 04:26:52PM -0400, Greg Smith wrote: - David Kerr wrote: - >the db, xlog and logs are all on separate areas of the SAN. - >separate I/O controllers, etc on the SAN. it's setup well, I wouldn't - >expect - >contention there. - > - - Just because you don't expect it doesn't mean it's not there. - Particularly something as complicated as a SAN setup, presuming anything - without actually benchmarking it is a recipe for fuzzy diagnostics when - problems pop up. If you took anyone's word that your SAN has good - performance without confirming it yourself, that's a path that's lead - many to trouble. that's actually what I'm doing, performance testing this environment. everything's on the table for me at this point. - Anyway, as Robert already stated, effective_cache_size only impacts how - some very specific types of queries are executed; that's it. If there's - some sort of query behavior involved in your load, maybe that has - something to do with your slowdown, but it doesn't explain general slow - performance. Other possibilities include that something else changed - when you reloaded the server as part of that, or it's a complete - coincidence--perhaps autoanalyze happened to finish at around the same - time and it lead to new plans. Ok that's good to know. I didn't think it would have any impact, and was surprised when it appeared to. I just finished running the test on another machine and wasn't able to reproduce the problem, so that's good news in some ways. But now i'm back to the drawing board. I don't think it's anything in the Db that's causing it. ( drop and re-create the db between tests) I actually suspect a hardware issue somewhere. Dave