On Sat, 17 Feb 2001, Tom Lane wrote:
> the default -B is way too small for WAL.
OK, here are some 2.4 numbers with 1K transactions/client
and -B10240.
> Huh? With the exception of the 16-user case (possibly measurement
> noise), 2.4 looks better across the board, AFAICS. But see below.
OK.
Rough methodology:
# service postgresql stop
# rpm -e postgresql-server
# rm -fr /var/lib/pgsql
# service postgresql start
# reboot
# sysctl -w kernel.shmmax=186048768
pg$ creatuser matthew
pg$ createdb matthew
me$ ./pgbench -i -s5 -t$T -c$N
Does this look fairly immune to troubles?
> > 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...
Ah, good point. Here are some with 2.4.2pre2 and 1000 transactions.
I'll try to find time tomorrow to do some batch benching with 10K
transactions on various kernels.
I hear allegations that the 2.4.1 disk elevator and VM are subject
to investigation to I'll try to keep some up-to-date numbers if any-
one is interested.
Matthew.
--
Numbers:
2.4.2-pre2 (-B10240):
pgbench -s5 -i: 1:13:02 elapsedpgbench -s5 -t10001: 40.06 / 40.10 TPS2: 53.01 / 53.084: 57.14 / 57.238: 62.82 /
62.9216:62.46 / 62.5632: 43.15 / 43.201: 23.48 / 26.051: 30.85 / 30.88
pgbench -v -s5 -t10001: 26.37 / 26.39
