Bill Montgomery wrote:
Alan Stange wrote:
Here's a few numbers from the Opteron 250. If I get some time I'll post a more comprehensive comparison including some other systems.
The system is a Sun v20z. Dual Opteron 250, 2.4Ghz, Linux 2.6, 8 GB memory. I did a compile and install of pg 8.0 beta 3. I created a data base on a tmpfs file system and ran pgbench. Everything was "out of the box", meaning I did not tweak any config files.
I used this for pgbench: $ pgbench -i -s 32
and this for pgbench invocations: $ pgbench -s 32 -c 1 -t 10000 -v
clients tps 1 1290 2 1780 4 1760 8 1680 16 1376 32 904
The same test on a Dell PowerEdge 1750, Dual Xeon 3.2 GHz, 512k cache, HT on, Linux 2.4.21-20.ELsmp (RHEL 3), 4GB memory, pg 7.4.5:
$ pgbench -i -s 32 pgbench $ pgbench -s 32 -c 1 -t 10000 -v
clients tps avg CS/sec ------- ----- ---------- 1 601 48,000 2 889 77,000 4 1006 80,000 8 985 59,000 16 966 47,000 32 913 46,000
Far less performance that the Dual Opterons with a low number of clients, but the gap narrows as the number of clients goes up. Anyone smarter than me care to explain?
boy, did Thunderbird ever botch the format of the table I entered...
I thought the falloff at 32 clients was a bit steep as well. One thought that crossed my mind is that "pgbench -s 32 -c 32 ..." might not be valid. From the pgbench README:
-s scaling_factor
this should be used with -i (initialize) option.
number of tuples generated will be multiple of the
scaling factor. For example, -s 100 will imply 10M
(10,000,000) tuples in the accounts table.
default is 1. NOTE: scaling factor should be at least
as large as the largest number of clients you intend
to test; else you'll mostly be measuring update contention.Another possible cause is the that pgbench process is cpu starved and isn't able to keep driving the postgresql processes. So I ran pgbench from another system with all else the same. The numbers were a bit smaller but otherwise similar.
I then reran everything using -s 64:
clients tps 1 1254 2 1645 4 1713 8 1548 16 1396 32 1060
Still starting to head down a bit. In the 32 client case, the system was ~60% user time, ~25% sytem and ~15% idle. Anyway, the machine is clearly hitting some contention somewhere. It could be in the tmpfs code, VM system, etc.
-- Alan
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
