Hello,
First of all: many thanks Tom for pointed me out what I made wrong and
Jim for 'spikes'.
I made some new tests:
available at http://85.128.68.44
What have changed since last time:
- database engine - now it's 8.1.0
- number of clients - "-c 20 "
- number of transactions - "-t 1000"
Really seems that you have made EXCELLENT work. Performance increased
about 25% in 8.1.0.
I also made some changes related with bg_write and wal (according to Jim):
bg_writer_all_percent = 0.433
bg_writer_all_maxpages = 15
wal_buffers = 8192
However I still can see 'spikey' performance but not as much as before
changes. What can I do more to eliminate or smooth these spikes? I
tried to increase bg_writer_all_xxx parameters but.... spikes still
exists ;).
Regards,
Marcin
This is pretty nearly an ideal example of how NOT to use pg_bench :-(
In the first place, don't use a number of clients (-c) much exceeding
the scale factor (-s). If you do, then almost all you are measuring is
the effects of update contention. There are only scale-factor rows in
the branches table, and every pgbench transaction wants to update one of
the branches rows, so with -c 100 and -s 20 there are on average going
to be 5 transactions simultaneously trying to modify the same branches
row. 4 of them are going to be waiting. Does that really correspond
to a real-world situation that you want to optimize?
In the second place, you need a run length considerably longer than
-t 100 to avoid getting swamped by noise of startup/shutdown overhead.
I usually use at least -t 1000 if I want repeatable numbers.
BTW, PG 8.1 will probably do better than 8.0 on multi-CPU hardware.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
