Re: bgwriter changes

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Mark Kirkwood <markir(at)coretech(dot)co(dot)nz>
Cc: Neil Conway <neilc(at)samurai(dot)com>, Mark Wong <markw(at)osdl(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: bgwriter changes
Date: 2004-12-20 08:01:43
Message-ID: 1103529703.2893.113.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2004-12-20 08:31:26 Re: Shared row locking
Previous Message Gavin Sherry 2004-12-20 07:23:24 Re: Shared row locking