Tom Lane wrote:
>
> Hannu Krosing <hannu@tm.ee> writes:
> > ./pgbench -i -s 10 -p 5433
> > ./pgbench -p 5433 -c 1 -t 100 171/177 162/166 169/173
> > ./pgbench -p 5433 -c 5 -t 100 140/143 191/196 202/207
> > ./pgbench -p 5433 -c 10 -t 100 132/135 165/168 159/163
> > ./pgbench -p 5433 -c 25 -t 100 65/ 66 60/ 60 75/ 76
> > ./pgbench -p 5433 -c 50 -t 100 60/ 61 43/ 43 55/ 59
> > ./pgbench -p 5433 -c 100 -t 100 48/ 48 23/ 23 34/ 34
>
> You realize, of course, that when the number of clients exceeds the
> scale factor you're not really measuring anything except update
> contention on the "branch" rows? Every transaction tries to update
> the balance for its branch, so if you have more clients than branches
> then there will be lots of transactions blocked waiting for someone
> else to commit. With a 10:1 ratio, there will be several transactions
> blocked waiting for *each* active transaction; and when that guy
> commits, all the others will waken simultaneously and contend for the
> chance to update the branch row. One will win, the others will go
> back to sleep, having done nothing except wasting CPU time. Thus a
> severe falloff in measured TPS is inevitable when -c >> -s. I don't
> think this scenario has all that much to do with real-world loads,
> however.
I did some benchmarking and the interesting part is that 7.2b4 is up to
2.5X faster than 7.1.3 for _small_ scale factors and up to 25% slower
when there is no contention (-s128, clients <= 128)
Perhaps the waiting on lock somehow organizes things to happen in some
order that avoids some stupidity in some other locking logic ?
I run benchmark (with added vacuum full for 7.2b4) on Dual PIII 800MHz
with 1 G of RAM and an IDE disk. The results are mean from six runs
with two slowes removed (there was other activity going on sometimes)
they are for scale factors 1, 10 and 128
in order to measure real performance of roughly the _same_ dataset each
test run did the same total number of transactions 512 with each client
doing 512/nr_of_trx.
