From: | Marcin Giedz <marcin(dot)giedz(at)eulerhermes(dot)pl> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: Xeon vs Opteron - second revision - tests and questions |
Date: | 2005-11-11 18:39:59 |
Message-ID: | 4374E57F.5030201@eulerhermes.pl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
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
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-11-11 19:11:57 | Re: Xeon vs Opteron - second revision - tests and questions |
Previous Message | Joshua D. Drake | 2005-11-11 17:17:32 | Re: upgrade |