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
