From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Matthew Kirkwood <matthew(at)hairy(dot)beasts(dot)org> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Linux 2.2 vs 2.4 |
Date: | 2001-02-18 00:21:43 |
Message-ID: | 6833.982455703@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Matthew Kirkwood <matthew(at)hairy(dot)beasts(dot)org> writes:
> No options changed from defaults. (I'll look at
> that tomorrow -- is there anything worth changing other than
> commit_delay and fsync?)
-B for sure ... the default -B is way too small for WAL.
> Firstly, it looks like 2.4 is mixed news for heavy pgbench users
> :) Low-utilisation numbers are better, but the sweet spot seems
> lower and narrower.
Huh? With the exception of the 16-user case (possibly measurement
noise), 2.4 looks better across the board, AFAICS. But see below.
> Secondly, in both occasions after a run, performance has been
> more than 20% lower.
I find that pgbench's reported performance can vary quite a bit from run
to run, at least with smaller values of total transactions. I think
this is because it's a bit of a crapshoot how many WAL logfile
initializations occur during the run and get charged against the total
time. Not to mention whatever else the machine might be doing. With
longer runs (say at least 10000 total transactions) the numbers should
stabilize. I wouldn't put any faith at all in tests involving less
than about 1000 total transactions...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-02-18 00:28:16 | Re: Microsecond sleeps with select() |
Previous Message | Brent Verner | 2001-02-18 00:10:09 | Re: Re: WAL and commit_delay |