Received: from maia.hub.org (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 9274D632CF2 for ; Tue, 20 Apr 2010 14:39:48 -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 60814-03 for ; Tue, 20 Apr 2010 17:39:27 +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 CFCC5632954 for ; Tue, 20 Apr 2010 14:39:37 -0300 (ADT) Received: by vexbert.mr-paradox.net (Postfix, from userid 18391) id D4317845CD; Tue, 20 Apr 2010 13:39:36 -0400 (EDT) Date: Tue, 20 Apr 2010 10:39:36 -0700 From: David Kerr To: pgsql-performance@postgresql.org Subject: Very high effective_cache_size == worse performance? Message-ID: <20100420173936.GA50886@mr-paradox.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.11 tagged_above=-10 required=5 tests=AWL=-0.200, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201004/241 X-Sequence-Number: 38491 Howdy all, I've got a huge server running just postgres. It's got 48 cores and 256GB of ram. Redhat 5.4, Postgres 8.3.9. 64bit OS. No users currently. I've got a J2EE app that loads data into the DB, it's got logic behind it so it's not a simple bulk load, so i don't think we can use copy. Based on the tuning guides, it set my effective_cache_size to 128GB (1/2 the available memory) on the box. When I ran my load, it took aproximately 15 hours to do load 20 million records. I thought this was odd because on a much smaller machine I was able to do that same amount of records in 6 hours. My initial thought was hardware issues so we got sar, vmstat, etc all running on the box and they didn't give any indication that we had resource issues. So I decided to just make the 2 PG config files look the same. (the only change was dropping effective_cache_size from 128GB to 2GB). Now the large box performs the same as the smaller box. (which is fine). incidentally, both tests were starting from a blank database. Is this expected? Thanks! Dave