Re: Checkpoint Tuning Question

From: Dan Armbrust <daniel(dot)armbrust(dot)list(at)gmail(dot)com>
To: pgsql general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Checkpoint Tuning Question
Date: 2009-07-09 16:03:00
Message-ID: 82f04dc40907090903j99f098euf87549103abb9590@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> As Greg commented upthread, we seem to be getting forced to the
> conclusion that the initial buffer scan in BufferSync() is somehow
> causing this.  There are a couple of things it'd be useful to try
> here:
>
> * see how the size of the hiccup varies with shared_buffers;

I tried decreasing shared buffers - both 25MB and 50MB were too small
for my load - I had slow queries at all times.

So then I increased it from what I was using - 100MB - to 500MB - and
the hiccup roughly doubles in length.

At 100MB, the hiccup is about 2-3 seconds long.
At 500MB, the hiccup is about 6 seconds long.

>
> * try inserting a delay into that scan loop, as per attached
>  quick-and-dirty patch.  (Numbers pulled from the air, but
>  we can worry about tuning after we see if this is really
>  where the problem is.)
>

After finally getting this particular system into a state where I
could build postgres (I was using the binary install) I built a 8.3.4,
using your patch - but I didn't see any change in the behaviour. I
see hiccups that appear to be the same length as I saw on the binary
build of 8.3.4.

Thanks,

Dan

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Arndt Lehmann 2009-07-09 16:12:42 Re: Table replication
Previous Message Pavel Stehule 2009-07-09 15:56:26 Re: SELECT DISTINCT very slow