Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)

Tom Lane wrote:
> Well, yes they are. They cause unnecessary process wakeups and thereby
> consume cycles even when the database is idle. See for example a
> longstanding complaint here:
> https://bugzilla.redhat.com/show_bug.cgi?id=252129
>
> If we're going to go to the trouble of having a mechanism like this,
> I'd like it to fix that problem so I can close out that bug.
>

The way the background writer wakes up periodically to absorb fsync
requests is already way too infrequent on a busy system. That component
of the bug report reeks as "not a bug" to me. Don't like the default?
Increase bgwriter_delay; move on with your life. We're not going to
increase the default, to screw over regular users, just to instead
prioritize people who prefer low power consumption. There's a knob for
it, you can tune the other way if you want. And based on this pile of
data I'm sorting through the last few weeks, my guess is that if the
default is going anywhere in 9.1 it's to make the BGW run *more* often,
not less. What those asking for the default change don't realize is
that if the BGW stops doing useful work, backends will start doing more
disk writes with their own fsync calls, and now you've just messed with
out how often the disks have to be powered up. I could probably
construct a test case that uses more power with the behavior they think
they want than the current one does. The only clear case where this is
always a win is when the system it totally idle.

The complaint that there's no similar way to detune the logger for lower
power use, something you can't really tweak on your own, is a much more
reasonable demand.

I have a patch that adds a new column to pg_stat_bgwriter to count how
often backend fsync calls happen directly, because the background writer
couldn't be bothered to absorb them. If this latching idea goes
somewhere, that should be a reasonable way to measure if the new
implementation is getting in the way of that particular processing
requirement. It's important to realize that the fsync absorb function
of the background writer has become absolutely critical on modern
systems that hit high transaction rates, so any refactoring of its basic
design needs to stay responsive to those incoming backend requests. I
don't see any high-level issues with the latch design approach Heikki
has proposed in regards to that. I'll take a look at some of the other
test cases I have here to see if they can help quantify its impact on
this aspect of BGW behavior.

--
Greg Smith 2ndQuadrant US Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.us