On 26 January 2012 16:48, Heikki Linnakangas 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
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