On Mon, 2004-12-20 at 01:17, Mark Kirkwood wrote:
> Mark Kirkwood wrote:
>
> > It occurs to me that cranking up the number of transactions (say
> > 1000->100000) and seeing if said regression persists would be
> > interesting. This would give the smoothing effect of the bgwriter
> > (plus the ARC) a better chance to shine.
>
> I ran a few of these over the weekend - since it rained here :-) , and
> the results are quite interesting:
>
> [2xPIII, 2G, 2xATA RAID 0, FreeBSD 5.3 with the same non default Pg
> parameters as before]
>
> clients = 4 transactions = 100000 (/client), each test run twice
>
> Version tps
> 7.4.6 49
> 8.0.0.0RC1 50
> 8.0.0.0RC1 + rem 49
> 8.0.0.0RC1 + bg2 50
>
> Needless to way, all well within measurement error of each other (the
> variability was about 1).
>
> I suspect that my previous tests had too few transactions to trigger
> many (or any) checkpoints. With them now occurring in the test, they
> look to be the most significant factor (contrast with 70-80 tps for 4
> clients with 1000 transactions).
>
> Also with a small number of transactions, the fsyn'ed blocks may have
> all fitted in the ATA disk caches (2x2M). In hindsight I should have
> disabled this! (might run the smaller no. transactions again with
> hw.ata.wc=0 and see if this is enlightening)
These test results do seem to have greatly reduced variability: thanks.
>From what you say, this means parameter setting were: (?)
shared_buffers = 10000
bgwriter_delay = 200
bgwriter_maxpages = 100
My interpretation of this is that the bgwriter is not effective with
these (the default) parameter settings.
I think the optimum performance is by reducing both bgwriter_delay and
bgwriter_maxpages, though reducing the delay isn't sensibly possible
with 8.0RCn when shared_buffers is large.
--
Best Regards, Simon Riggs