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

From Alan Stange
Subject Re: Excessive context switching on SMP Xeons
Date
Msg-id 4163EF16.3030804@rentec.com
Whole thread Raw
In response to Re: Excessive context switching on SMP Xeons  (Greg Stark <gsstark@mit.edu>)
List pgsql-performance
Greg Stark wrote:

>Alan Stange <stange@rentec.com> writes:
>
>
>>A few quick random observations on the Xeon v. Opteron comparison:
>>
>>- running a dual Xeon with hyperthreading turned on really isn't the same as
>>having a quad cpu system. I haven't seen postgresql specific benchmarks, but
>>the general case has been that HT is a benefit in a few particular work
>>loads but with no benefit in general.
>>
>>
>Part of the FUD with hyperthreading did have a kernel of truth that lied in
>older kernels' schedulers. For example with Linux until recently the kernel
>can easily end up scheduling two processes on the two virtual processors of
>one single physical processor, leaving the other physical processor totally
>idle.
>
>With modern kernels' schedulers I would expect hyperthreading to live up to
>its billing of adding 10% to 20% performance. Ie., a dual Xeon machine with
>hyperthreading won't be as fast as four processors, but it should be 10-20%
>faster than a dual Xeon without hyperthreading.
>
>As with all things that will only help if you're bound by the right limited
>resource to begin with. If you're I/O bound it isn't going to help. I would
>expect Postgres with its heavy demand on memory bandwidth and shared memory
>could potentially benefit more than usual from being able to context switch
>during pipeline stalls.
>
>
All true.   I'd be surprised if HT on an older 2.8 Ghz Xeon with only a
512K cache will see any real benefit.   The dual Xeon is already memory
starved, now further increase the memory pressure on the caches (because
the 512K is now "shared" by two virtual processors) and you probably
won't see a gain.  It's memory stalls all around.  To be clear, the
context switch in this case isn't a kernel context switch but a "virtual
cpu" context switch.

The probable reason we see dual Opteron boxes way outperforming dual
Xeons boxes is exactly because of Postgresql's heavy demand on memory.
The Opteron's have a much better memory system.

A quick search on google or digging around in the comp.arch archives
will provide lots of details.    HP's web site has (had?) some
benchmarks comparing these systems.  HP sells both Xeon and Opteron
systems, so the comparison were quite "fair".  Their numbers showed the
Opteron handily outperfoming the Xeons.

-- Alan

pgsql-performance by date:

Previous
From: Pierre-Frédéric Caillaud
Date:
Subject: Re: sequential scan on select distinct
Next
From: Tom Lane
Date:
Subject: Re: stats on cursor and query execution troubleshooting