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 ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
