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
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 |