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 think you are right that the difference between 7.1 and 7.2 may have
more to do with the change in VACUUM strategy than anything else. Could
you retry the test after changing all the "vacuum" commands in pgbench.c
to "vacuum full"?
regards, tom lane