On 26 January 2012 16:48, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.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
