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 gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
