On Sun, Nov 14, 2010 at 3:48 PM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> One change that turned out be necessary rather than optional--to get good
> performance from the system under tuning--was to make regular background
> writer activity, including fsync absorb checks, happen during these sync
> pauses. The existing code ran the checkpoint sync work in a pretty tight
> loop, which as I alluded to in an earlier patch today can lead to the
> backends competing with the background writer to get their sync calls
> executed. This squashes that problem if the background writer is setup
Have you tested out this "absorb during syncing phase" code without
the sleep between the syncs?
I.e. so that it still a tight loop, but the loop alternates between
sync and absorb, with no intentional pause?
I wonder if all the improvement you see might not be due entirely to
the absorb between syncs, and none or very little from
the sleep itself.
I ask because I don't have a mental model of how the pause can help.
Given that this dirty data has been hanging around for many minutes
already, what is a 3 second pause going to heal?
The healing power of clearing out the absorb queue seems much more obvious.
In response to
pgsql-hackers by date
|Next:||From: Bruce Momjian||Date: 2010-12-01 01:35:56|
|Subject: Re: crash-safe visibility map, take three|
|Previous:||From: Jeff Davis||Date: 2010-11-30 22:21:07|
|Subject: Re: DELETE with LIMIT (or my first hack)|