Received: from localhost (maia-1.hub.org [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id 8A8E99FA217 for ; Wed, 17 Jan 2007 19:14:12 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-new, port 10024) with ESMTP id 50202-04 for ; Wed, 17 Jan 2007 19:13:54 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from exchange.g2switchworks.com (mail.g2switchworks.com [63.87.162.25]) by postgresql.org (Postfix) with ESMTP id B60719FA176 for ; Wed, 17 Jan 2007 19:13:54 -0400 (AST) Received: from 10.10.1.37 ([10.10.1.37]) by exchange.g2switchworks.com ([10.10.1.2]) with Microsoft Exchange Server HTTP-DAV ; Wed, 17 Jan 2007 23:13:51 +0000 Received: from state.g2switchworks.com by mail.g2switchworks.com; 17 Jan 2007 17:13:51 -0600 Subject: Re: Configuration Advice From: Scott Marlowe To: Steve Cc: Benjamin Minshall , pgsql-performance@postgresql.org In-Reply-To: References: <1168982580.8275.1169588211@webmail.messagingengine.com> <26412.1168983547@sss.pgh.pa.us> <1168986053.16393.1169598917@webmail.messagingengine.com> <81961ff50701161444l3f932755m5a6e15ad2d948130@mail.gmail.com> <1169002739.19758.1169636285@webmail.messagingengine.com> <1169012767.6271.7.camel@localhost.localdomain> <1169044649.19974.1169715743@webmail.messagingengine.com> <1169050746.9586.44.camel@state.g2switchworks.com> <45AE79D5.9080000@fuzzy.cz> <45AE962A.5070408@intellicon.biz> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1169075631.9586.61.camel@state.g2switchworks.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 17 Jan 2007 17:13:51 -0600 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200701/287 X-Sequence-Number: 22888 On Wed, 2007-01-17 at 15:58, Steve wrote: > On Wed, 17 Jan 2007, Benjamin Minshall wrote: > > > > >> Building these indexes takes forever! > > > >> Anyway -- ANYTHING we can do to make this go faster is appreciated :) > >> Here's some vital statistics: > > > >> - Machine is a 16 GB, 4 actual CPU dual-core opteron system using SCSI > >> discs. The disc configuration seems to be a good one, it's the best of all > >> the ones we've tested so far. > > > > What are your shared_buffers, work_mem, and maintenance_work_mem settings? > > > > maintenance_work_mem is used for CREATE INDEX, and with 16GB of memory in the > > machine, maintenance_work_mem should be set to at least 1GB in my opinion. > > > > shared_buffers = 8GB > work_mem = 256MB > maintenance_work_mem = 6GB > > So that should be covered, unless I'm using too much memory and swapping. > It does look like it's swapping a little, but not too badly as far as I > can tell. I'm thinking of dialing back everything a bit, but I'm not > really sure what the heck to do :) It's all guessing for me right now. Generally speaking, once you've gotten to the point of swapping, even a little, you've gone too far. A better approach is to pick some conservative number, like 10-25% of your ram for shared_buffers, and 1 gig or so for maintenance work_mem, and then increase them while exercising the system, and measure the difference increasing them makes. If going from 1G shared buffers to 2G shared buffers gets you a 10% increase, then good. If going from 2G to 4G gets you a 1.2% increase, it's questionable. You should reach a point where throwing more shared_buffers stops helping before you start swapping. But you might not. Same goes for maintenance work mem. Incremental changes, accompanied by reproduceable benchmarks / behaviour measurements are the way to determine the settings. Note that you can also vary those during different times of the day. you can have maint_mem set to 1Gig during the day and crank it up to 8 gig or something while loading data. Shared_buffers can't be changed without restarting the db though.