DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=j1fUZ2Fbhmw5a4OFVS9N0HNEW6PVkP1paho8PC8yM+6Zs93ud87u1a5PgcaqKoyNxdhdCJO8+BhA4x2GDuvy1wETM3pKznnXCWS0Ph2sBpHNNpcsGvS7XtvXCmcEW/PuLknMjs6lzREadApRlTv/IrCF3an8rKnaKe62x1QqcKM=
Message-ID: <59d991c405071909341a10143@mail.gmail.com>
Date: Tue, 19 Jul 2005 12:34:19 -0400
From: Christopher Petrilli <petrilli@gmail.com>
Reply-To: Christopher Petrilli <petrilli@gmail.com>
To: PFC <lists@boutiquenumerique.com>
Subject: Re: Impact of checkpoint_segments under continual load conditions
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Vivek Khera <vivek@khera.org>,
	pgsql-performance@postgresql.org
In-Reply-To: <op.st549abtth1vuj@localhost>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <59d991c4050717100874c08a86@mail.gmail.com>
	<59d991c405071811457ccdd3f1@mail.gmail.com>
	<16394.1121715156@sss.pgh.pa.us>
	<59d991c405071812342e290f57@mail.gmail.com>
	<16794.1121718743@sss.pgh.pa.us>
	<59d991c405071907482bb0689b@mail.gmail.com>
	<op.st52tvunth1vuj@localhost>
	<59d991c4050719084460b376f1@mail.gmail.com>
	<4541.1121788647@sss.pgh.pa.us> <op.st549abtth1vuj@localhost>

On 7/19/05, PFC <lists@boutiquenumerique.com> wrote:
>=20
>=20
> > I think PFC's question was not directed towards modeling your
> > application, but about helping us understand what is going wrong
> > (so we can fix  it).
>=20
>         Exactly, I was wondering if this delay would allow things to get =
flushed,
> for instance, which would give information about the problem (if giving i=
t
> a few minutes of rest resumed normal operation, it would mean that some
> buffer somewhere is getting filled faster than it can be flushed).
>=20
>         So, go ahead with a few minutes even if it's unrealistic, that is=
 not the
> point, you have to tweak it in various possible manners to understand the
> causes.

Totally understand, and appologize if I sounded dismissive.  I
definately appreciate the insight and input.
=20
>         And instead of a pause, why not just set the duration of your tes=
t to
> 6000 iterations and run it two times without dropping the test table ?

This I can do.   I'll probably set it for 5,000 for the first, and
then start the second.  In non-benchmark experience, however, this
didn't seem to make much difference.

>         I'm going into wild guesses, but first you should want to know if=
 the
> problem is because the table is big, or if it's something else. So you ru=
n
> the complete test, stopping a bit after it starts to make a mess, then
> instead of dumping the table and restarting the test anew, you leave it a=
s
> it is, do something, then run a new test, but on this table which already
> has data.
>=20
>         'something' could be one of those :
>         disconnect, reconnect (well you'll have to do that if you run the=
 test
> twice anyway)
>         just wait
>         restart postgres
>         unmount and remount the volume with the logs/data on it
>         reboot the machine
>         analyze
>         vacuum
>         vacuum analyze
>         cluster
>         vacuum full
>         reindex
>         defrag your files on disk (stopping postgres and copying the data=
base
>  from your disk to anotherone and back will do)
>         or even dump'n'reload the whole database
>=20
>         I think useful information can be extracted that way. If one of t=
hese
> fixes your problem it'l give hints.
>=20

This could take a while :-)

Chris
--=20
| Christopher Petrilli
| petrilli@gmail.com