Received: from maia.hub.org (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 8BBFB633D01 for ; Tue, 20 Apr 2010 17:27:30 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 02623-03-2 for ; Tue, 20 Apr 2010 20:27:07 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by mail.postgresql.org (Postfix) with ESMTP id A678D633EAA for ; Tue, 20 Apr 2010 17:26:57 -0300 (ADT) Received: from [192.168.0.105] (pool-96-244-14-10.bltmmd.fios.verizon.net [96.244.14.10]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0Lvx1t-1NNwlH0HFN-018KKs; Tue, 20 Apr 2010 22:26:55 +0200 Message-ID: <4BCE0E0C.1020903@2ndquadrant.com> Date: Tue, 20 Apr 2010 16:26:52 -0400 From: Greg Smith User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: David Kerr CC: Scott Marlowe , Nikolas Everett , Robert Haas , pgsql-performance@postgresql.org Subject: Re: Very high effective_cache_size == worse performance? References: <20100420173936.GA50886@mr-paradox.net> <20100420180351.GA51940@mr-paradox.net> <20100420182030.GA53489@mr-paradox.net> <20100420182832.GB53489@mr-paradox.net> In-Reply-To: <20100420182832.GB53489@mr-paradox.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX19x36NeigpKMseNHTvI+RxKloO0myn0Gexd0bl RQ62drc5Nv2qxpQSQ8bV57DNgrOn7ONscAGpWzVdqURN8NfOYq 7P1LEMXTNNmNWibMAEFgSsprTPCtRSl X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.032 tagged_above=-10 required=5 tests=AWL=-1.031, BAYES_40=-0.001 X-Spam-Level: X-Archive-Number: 201004/265 X-Sequence-Number: 38515 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. 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. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us