Re: Xeon vs Opteron - second revision - tests and questions

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
>
>
>