Re: Excessive context switching on SMP Xeons

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