From: Scott Marlowe <smarlowe@g2switchworks.com>
To: Steve <cheetah@tanabi.org>
Cc: Benjamin Minshall <minshall@intellicon.biz>
Cc: pgsql-performance@postgresql.org
Subject: Re: Configuration Advice
Date: Thu, 18 Jan 2007 09:38:32 -0600
Message-ID: <1169134712.9586.63.camel@state.g2switchworks.com> (raw)
In-Reply-To: <Pine.GSO.4.64.0701171924200.4471@kingcheetah.tanabi.org>
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>
<Pine.GSO.4.64.0701171445570.4471@kingcheetah.tanabi.org>
<45AE962A.5070408@intellicon.biz>
<Pine.GSO.4.64.0701171656450.4471@kingcheetah.tanabi.org>
<1169075631.9586.61.camel@state.g2switchworks.com>
<Pine.GSO.4.64.0701171924200.4471@kingcheetah.tanabi.org>
On Wed, 2007-01-17 at 18:27, Steve wrote:
> > 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.
> >
>
> I'm currently benchmarking various configuration adjustments. Problem is
> these tests take a really long time because I have to run the load
> process... which is like a 9 hour deal. That's why I'm asking for advice
> here, because there's a lot of variables here and it's really time costly
> to test :)
>
> I'm still working on the benchmarkings and by Friday I should have some
> interesting statistics to work with and maybe help figure out what's going
> on.
You can probably take a portion of what you're loading and make a
benchmark of the load process that is repeatable (same data, size,
etc...) each time, but only takes 30 minutes to an hour to run each
time. shortens your test iteration AND makes it reliably repeatable.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: smarlowe@g2switchworks.com, cheetah@tanabi.org, minshall@intellicon.biz
Subject: Re: Configuration Advice
In-Reply-To: <1169134712.9586.63.camel@state.g2switchworks.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox