On 26 January 2012 16:48, Heikki Linnakangas <heikki.linnakan...@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
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 (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers