Re: hyperthreaded cpu still an issue in 8.4?

On 7/28/09 1:58 PM, "Merlin Moncure" <mmoncure(at)gmail(dot)com> wrote:

> On Mon, Jul 27, 2009 at 2:05 PM, Dave Youatt<dave(at)meteorsolutions(dot)com> wrote:
>> On 01/-10/-28163 11:59 AM, Greg Smith wrote:
>>> On Tue, 21 Jul 2009, Doug Hunley wrote:
>>>
>>>> Just wondering is the issue referenced in
>>>> http://archives.postgresql.org/pgsql-performance/2005-11/msg00415.php
>>>> is still present in 8.4 or if some tunable (or other) made the use of
>>>> hyperthreading a non-issue. We're looking to upgrade our servers soon
>>>> for performance reasons and am trying to determine if more cpus (no
>>>> HT) or less cpus (with HT) are the way to go.
>>>
>>> If you're talking about the hyperthreading in the latest Intel Nehalem
>>> processors, I've been seeing great PostgreSQL performance from those.
>>> The kind of weird behavior the old generation hyperthreading designs
>>> had seems gone.  You can see at
>>> http://archives.postgresql.org/message-id/alpine.GSO.2.01.0907222158050.1671
>>> 3(at)westnet(dot)com
>>> that I've cleared 90K TPS on a 16 core system (2 quad-core
>>> hyperthreaded processors) running a small test using lots of parallel
>>> SELECTs.  That would not be possible if there were HT spinlock
>>> problems still around. There have been both PostgreSQL scaling
>>> improvments and hardware improvements since the 2005 messages you saw
>>> there that have combined to clear up the issues there.  While true
>>> cores would still be better if everything else were equal, it rarely
>>> is, and I wouldn't hestitate to jump on Intel's bandwagon right now.
>>
>> Greg, those are compelling numbers for the new Nehalem processors.
>> Great news for postgresql.  Do you think it's due to the new internal
>> interconnect, that bears a strong resemblance to AMD's hypertransport
> [snip]
>
> as a point of reference, here are some numbers on a quad core system
> (2xintel 5160) using the old pgbench, scaling factor 10:
>
> pgbench -S -c 16 -t 10000
> starting vacuum...end.
> transaction type: SELECT only
> scaling factor: 10
> query mode: simple
> number of clients: 16
> number of transactions per client: 10000
> number of transactions actually processed: 160000/160000
> tps = 24088.807000 (including connections establishing)
> tps = 24201.820189 (excluding connections establishing)
>
> This shows actually my system (pre-Nehalem) is pretty close clock for
> clock, albeit thats not completely fair..I'm using only 4 cores on
> dual core procs. Still, these are almost two years old now.
>
> EDIT: I see now that Greg has only 8 core system not counting
> hyperthreading...so I'm getting absolutely spanked! Go Intel!
>
> Also, I'm absolutely dying to see some numbers on the high end
> W5580...if anybody has one, please post!
>
> merlin

Note, that a 5160 is a bit behind. The 52xx and 54xx series were a decent
perf boost on their own, with more cache, and usually more total system
bandwidth too (50% more than 51xx and 53xx is typical).

But the leap to 55xx is far bigger!

>
> --
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>