On 26 January 2012 16:48, Heikki Linnakangas
<[email protected]> 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
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
new file mode 100644
index 309b6a5..0e4dd97
*** a/doc/src/sgml/config.sgml
--- b/doc/src/sgml/config.sgml
*************** SET ENABLE_SEQSCAN TO OFF;
*** 1318,1334 ****
</indexterm>
<listitem>
<para>
! Specifies the delay between activity rounds for the
! background writer. In each round the writer issues writes
! for some number of dirty buffers (controllable by the
! following parameters). It then sleeps for <varname>bgwriter_delay</>
! milliseconds, and repeats. The default value is 200 milliseconds
! (<literal>200ms</>). Note that on many systems, the effective
! resolution of sleep delays is 10 milliseconds; setting
! <varname>bgwriter_delay</> to a value that is not a multiple of
! 10 might have the same results as setting it to the next higher
! multiple of 10. This parameter can only be set in the
! <filename>postgresql.conf</> file or on the server command line.
</para>
</listitem>
</varlistentry>
--- 1318,1335 ----
</indexterm>
<listitem>
<para>
! Specifies the delay between activity rounds for the background writer.
! In each round the writer issues writes for some number of dirty buffers
! (controllable by the following parameters). It then sleeps for
! <varname>bgwriter_delay</> milliseconds, and repeats, though it will
! hibernate when it has looked through every buffer in
! <varname>shared_buffers</varname> without finding a dirty buffer. The
! default value is 200 milliseconds (<literal>200ms</>). Note that on
! many systems, the effective resolution of sleep delays is 10
! milliseconds; setting <varname>bgwriter_delay</> to a value that is not
! a multiple of 10 might have the same results as setting it to the next
! higher multiple of 10. This parameter can only be set in the
! <filename>postgresql.conf</> file or on the server command line.
</para>
</listitem>
</varlistentry>
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
