From: Christopher Petrilli <petrilli@gmail.com>
To: PFC <lists@boutiquenumerique.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Vivek Khera <vivek@khera.org>
Cc: pgsql-performance@postgresql.org
Subject: Re: Impact of checkpoint_segments under continual load conditions
Date: Tue, 19 Jul 2005 12:34:19 -0400
Message-ID: <59d991c405071909341a10143@mail.gmail.com> (raw)
In-Reply-To: <op.st549abtth1vuj@localhost>
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:
>
>
> > 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).
>
> Exactly, I was wondering if this delay would allow things to get flushed,
> for instance, which would give information about the problem (if giving it
> a few minutes of rest resumed normal operation, it would mean that some
> buffer somewhere is getting filled faster than it can be flushed).
>
> 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.
> And instead of a pause, why not just set the duration of your test 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 run
> 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 as
> it is, do something, then run a new test, but on this table which already
> has data.
>
> '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 database
> from your disk to anotherone and back will do)
> or even dump'n'reload the whole database
>
> I think useful information can be extracted that way. If one of these
> fixes your problem it'l give hints.
>
This could take a while :-)
Chris
--
| Christopher Petrilli
| petrilli@gmail.com
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: petrilli@gmail.com, lists@boutiquenumerique.com, tgl@sss.pgh.pa.us, vivek@khera.org
Subject: Re: Impact of checkpoint_segments under continual load conditions
In-Reply-To: <59d991c405071909341a10143@mail.gmail.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