Message-ID: <4E3B08D3.606@peak6.com>
Date: Thu, 4 Aug 2011 16:02:11 -0500
From: Shaun Thomas <sthomas@peak6.com>
Reply-To: <sthomas@peak6.com>
Organization: Peak6
User-Agent: Mozilla/5.0 (X11; Linux i686;
	rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>
CC: <pgsql-performance@postgresql.org>, Claire Chang <yenhsiac@yahoo.com>
Subject: Re: Postgres 8.4 memory related parameters
References: <1312489633.71838.YahooMailClassic@web31912.mail.mud.yahoo.com>
	<4E3ABCFB020000250003FAF4@gw.wicourts.gov>
In-Reply-To: <4E3ABCFB020000250003FAF4@gw.wicourts.gov>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
content-transfer-encoding: 7bit

On 08/04/2011 03:38 PM, Kevin Grittner wrote:

> You're probably going to get better performance by setting that to 2
> to 3 times the number of actual cores (don't county hyperthreading
> for this purpose), and using a connection pooler to funnel the 600
> user connections down to a smaller number of database connections.

Your note about Hyperthreading *used* to be true. I'm not sure exactly 
what they did to the Intel nehalem cores, but hyperthreading actually 
seems to be much better now. It's not a true multiplier, but our pgbench 
scores were 40% to 60% higher with HT enabled up to at least 5x the 
number of cores.

I was honestly shocked at those results, but they were consistent across 
multiple machines from two separate vendors.

-- 
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd. | Suite 800 | Chicago IL, 60604
312-676-8870
sthomas@peak6.com

______________________________________________

See  http://www.peak6.com/email_disclaimer.php
for terms and conditions related to this email