I took some time to figure out a reasonable tuning for my fresh 9.2.3
installation when I've noticed the following:
[costin@fsr costin]$ /home/pgsql/bin/pgbench -h 192.1.1.2 -p 5432 -U
postgres -i -s 1
...
100000 tuples done.
...
vacuum...done.
[costin@fsr costin]$ /home/pgsql/bin/pgbench -h 192.1.1.2 -p 5432 -U
postgres -c 32 -t 5000
...
tps = 245.628075 (including connections establishing)
tps = 245.697421 (excluding connections establishing)
...
[costin@fsr costin]$ /home/pgsql/bin/pgbench -h 192.1.1.2 -p 5432 -U
postgres -i -s 100
...
10000000 tuples done.
...
vacuum...done.
[costin@fsr costin]$ /home/pgsql/bin/pgbench -h 192.1.1.2 -p 5432 -U
postgres -c 32 -t 5000
...
tps = 1125.035567 (including connections establishing)
tps = 1126.490634 (excluding connections establishing)
32 connections makes a comfortable load for the 8 core 4GB production
server, a rather old machine. I kept testing for almost two days with
various configuration parameters. In the beginning I was warned to
increase the checkpoint_segments, which is now 32. The results were
consistent and always showing small scale test (-s 1) at about 245-248
tps while big scale test (-s 100) at least 4 and up to 7 times
better.
According to top, at small scale tests, server processes are doing a
lot of UPDATE waiting. A "select relation::regclass, * from pg_locks
where not granted" showed frequent contention on tellers rows.
First, I've got no good explanation for this and it would be nice to
have one. As far as I can understand this issue, the heaviest update
traffic should be on the branches table and should affect all tests.
Second, I'd really like to bring the small scale test close to a four
figure tps if it proves to be a matter of server configuration.
Thank you,
Costin Oproiu
