Skip site navigation (1) Skip section navigation (2)

Re: hyperthreaded cpu still an issue in 8.4?

From: Greg Smith <gsmith(at)gregsmith(dot)com>
To: Doug Hunley <doug(at)hunley(dot)homeip(dot)net>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: hyperthreaded cpu still an issue in 8.4?
Date: 2009-07-26 19:52:20
Message-ID: alpine.GSO.2.01.0907261539540.7506@westnet.com (view raw or flat)
Thread:
Lists: pgsql-performance
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.16713@westnet.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 Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD

In response to

Responses

pgsql-performance by date

Next:From: Robert HaasDate: 2009-07-26 21:15:13
Subject: Re: Performance of quer or procedure going down when we are taking the backup
Previous:From: nhaDate: 2009-07-26 16:28:36
Subject: Re: Nested loop Query performance on PK

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group