Re: Excessive context switching on SMP Xeons - Mailing list pgsql-performance

From Bill Montgomery
Subject Re: Excessive context switching on SMP Xeons
Date
Msg-id 41656559.70100@lulu.com
Whole thread Raw
In response to Re: Excessive context switching on SMP Xeons  (Alan Stange <stange@rentec.com>)
Responses Re: Excessive context switching on SMP Xeons
Re: Excessive context switching on SMP Xeons
List pgsql-performance
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?

Anyone have a 4-way Opteron to run the same benchmark on?

-Bill

> How are these results useful?  In some sense, this is a speed of light
> number for the Opteron 250.   You'll never go faster on this system
> with a real storage subsystem involved instead of a tmpfs file
> system.   It's also a set of numbers that anyone else can reproduce as
> we don't have to deal with any differences in file systems, disk
> subsystems, networking, etc.   Finally, it's a set of results that
> anyone else can compute on Xeon's or other systems and make a simple
> (and naive) comparisons.
>
>
> Just to stay on topic:   vmstat reported about 30K cs / second while
> this was running the 1 and 2 client cases.
>
> -- Alan



pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: sequential scan on select distinct
Next
From: Greg Stark
Date:
Subject: Re: sequential scan on select distinct