From: Kevin Grittner <Kevin.Grittner@wicourts.gov>
To: Evgeny Gridasov <eugrid@fpm.kubsu.ru>
Cc: pgsql-performance@postgresql.org
Subject: Re: Background writer configuration
Date: Fri, 17 Mar 2006 09:08:23 -0600
Message-ID: <441A7C87.EE98.0025.0@wicourts.gov> (raw)
In-Reply-To: <20060317152448.452e4854.eugrid@fpm.kubsu.ru>
References: <44181A11.EE98.0025.0@wicourts.gov>
<20060316211523.73343cee.eugrid@fpm.kubsu.ru>
<44198B3D.EE98.0025.0@wicourts.gov>
<20060317152448.452e4854.eugrid@fpm.kubsu.ru>
>>> On Fri, Mar 17, 2006 at 6:24 am, in message
<20060317152448.452e4854.eugrid@fpm.kubsu.ru>, Evgeny Gridasov
<eugrid@fpm.kubsu.ru> wrote:
>
> I've maid some tests with pgbench
If possible, tune the background writer with your actual application
code under normal load. Optimal tuning is going to vary based on usage
patterns. You can change these settings on the fly by editing the
postgresql.conf file and running pg_ctl reload. This is very nice, as
it allowed us to try various settings in our production environment
while two machines dealt with normal update and web traffic and another
was in a saturated update process.
For us, the key seems to be to get the dirty blocks pushed out to the
OS level cache as soon as possible, so that the OS can deal with them
before the checkpoint comes along.
> for all tests:
> checkpoint_segments = 16
> checkpoint_timeout = 900
> shared_buffers=65536
> wal_buffers=128:
> ./pgbench - c 32 - t 500 - U postgres regression
Unless you are going to be running in short bursts of activity, be sure
that the testing is sustained long enough to get through several
checkpoints and settle into a "steady state" with any caching
controller, etc. On the face of it, it doesn't seem like this test
shows anything except how it would behave with a relatively short burst
of activity sandwiched between big blocks of idle time. I think your
second test may look so good because it is just timing how fast it can
push a few rows into cache space.
> Setting bgwriter_delay to higher values leads to slower postgresql
shutdown time
> (I see postgresql writer process writing to disk). Sometimes
postgresql didn't
> shutdown correctly (doesn't complete background writing ?).
Yeah, here's where it gets to trying to finish all the work you avoided
measuring in your benchmark.
-Kevin
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: Kevin.Grittner@wicourts.gov, eugrid@fpm.kubsu.ru
Subject: Re: Background writer configuration
In-Reply-To: <441A7C87.EE98.0025.0@wicourts.gov>
* 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