Skip site navigation (1) Skip section navigation (2)

Re: BGWriter latch, power saving

From: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: BGWriter latch, power saving
Date: 2012-01-26 19:37:23
Message-ID: CAEYLb_UXX2x8gB7BctZZXSF32vtCxs1T_Up1SaDhSF-d48_pqg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On 26 January 2012 16:48, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> Ok, committed with some further cleanup.
>
> Do you think the docs need to be updated for this, and if so, where? The
> only place I found in the docs that speak about how the bgwriter works is in
> config.sgml, where bgwriter_delay is described. Want to suggest an update to
> that?

This new behaviour might warrant a mention, as in the attached doc-patch.

> I did some testing on this, with a highly artificial test case that dirties
> pages in shared_buffers as fast as possible. I tried to make it a worst-case
> scenario, see attached script. I tested this with a 32-core HP Itanium box,
> and on my 2-core laptop, and didn't see any measurable slowdown from this
> patch. So I think we're good.

Cool. I was pretty confident that it would be completely impossible to
show a regression under any circumstances, but I'm glad that you
tested it on a large server like that.

> BTW, do you have some sort of a test setup for these power-saving patches,
> to actually measure the effect on number of interrupts or electricity use?
> Fewer wakeups should be a good thing, but it would be nice to see some
> figures to get an idea of how much progress we've done and what still needs
> to be done.

The only thing I've been using is Intel's powertop utility. It is
pretty easy to see what's happening, and what you'll see is exactly
what you'd expect (So by process, I could see that the bgwriter had
exactly 5 wake-ups per second with bgwriter_delay at 200). It is
useful to sleep quite pro-actively, as CPUs will enter idle C-states
and move to lower P-states quite quickly (some will be more familiar
with the commercial names for P-states, such as Intel's speedstep
technology).  I might have been less conservative about the
circumstances that cause the bgwriter to go to sleep, but I was
conscious of the need to get something into this release.

It's difficult to know what a useful workload should be to show the
benefits of this work, apart from the obvious one, which is to show
Postgres when completely idle. I think we started at 11.5 wake-ups per
second, and I think that's down to about 6.5 now - the WAL Writer
still accounts for 5 of those, so that's why I feel it's particularly
important to get it done too, though obviously that's something that
should defer to however we end up implementing group commit.

I intend to blog about it in the next few days, and I'll present a
careful analysis of the benefits of this work there. Look out for it
on planet.

-- 
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services

Attachment: bgwriter_docs.patch
Description: text/x-patch (2.1 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2012-01-26 19:45:58
Subject: Re: Progress on fast path sorting, btree index creation time
Previous:From: Tom LaneDate: 2012-01-26 19:27:40
Subject: Re: WIP patch for parameterized inner paths

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group