Re: bgwriter changes - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: bgwriter changes
Date
Msg-id 1103529703.2893.113.camel@localhost.localdomain
Whole thread Raw
In response to Re: bgwriter changes  (Mark Kirkwood <markir@coretech.co.nz>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Gavin Sherry
Date:
Subject: Re: Shared row locking
Next
From: Simon Riggs
Date:
Subject: Re: Shared row locking