On Fri, 7 Sep 2007, Simon Riggs wrote:

For me, the bgwriter should sleep for at most 10ms at a time.

Here's the results I got when I pushed the time down significantly from the defaults, with some of the earlier results for comparision:

                     info                      | set | tps  | cleaner_pct
-----------------------------------------------+-----+------+-------------
 jit multiplier=2.0 scan_whole=120s delay=200ms|  17 |  981 |       99.98
 jit multiplier=1.0 scan_whole=120s delay=200ms|  18 |  970 |       99.99

 jit multiplier=1.0 scan_whole=120s delay=20ms |  20 |  956 |       92.34
 jit multiplier=2.0 scan_whole=120s delay=20ms |  21 |  967 |       99.94

 jit multiplier=1.5 scan_whole=120s delay=10ms |  22 |  944 |       97.91
 jit multiplier=2.0 scan_whole=120s delay=10ms |  23 |  981 |        99.7

It seems I have to push the multiplier higher to get good results when using a much lower interval, which was expected, but the fundamentals all scale down to the running much faster the way I'd hoped.

I'm tempted to make the default 10ms, adjust some of the other constants just a bit to optimize better for that time scale: make the default multiplier 2.0, increase the weighted average sample period, and perhaps reduce scan_whole a bit because that's barely doing anything at 10ms. If no one discovers any problems with working that way during beta, then consider locking them in for the RC. That would leave just the multiplier and maxpages as the exposed tunables, and it's very easy to tune maxpages just by watching pg_stat_bgwriter. This would obviously be a very aggressive plan--it would be eliminating GUCs and reducing flexibility for people in the field, aiming instead at making this more automatic for the average case.

If anyone has a reason why they feel the bgwriter_delay needs to be a tunable or why the rate might need to run even faster than 10ms, now would be a good time to say why.

--
* Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

               http://www.postgresql.org/about/donate

Reply via email to