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

Reply via email to