Re: bgwriter changes

From: Mark Kirkwood <markir(at)coretech(dot)co(dot)nz>
To: Mark Kirkwood <markir(at)coretech(dot)co(dot)nz>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, 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 01:17:58
Message-ID: 41C62846.6050206@coretech.co.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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)

regards

Mark

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2004-12-20 02:32:22 Re: Shared row locking
Previous Message Tom Lane 2004-12-20 00:36:45 Re: Kerberos includes (was Re: Port report: Fedora Core 3 x86_64)