Message-ID: <5134B327.9030207@comcast.net>
Date: Mon, 04 Mar 2013 09:43:51 -0500
From: AJ Weber <aweber@comcast.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Scott Marlowe <scott.marlowe@gmail.com>
CC: pgsql-performance@postgresql.org
Subject: Re: What setup would you choose for postgresql 9.2 installation?
References: <31E8EC2A-72E9-419A-9CDD-5B646A534272@autouncle.com>
	<5134AA00.6080800@comcast.net>
	<CAOR=d=1ObuuSJJpxfvJRRjdiOvPTTJiDkq-QN3Ycw3yWXcYUxg@mail.gmail.com>
In-Reply-To: 
 <CAOR=d=1ObuuSJJpxfvJRRjdiOvPTTJiDkq-QN3Ycw3yWXcYUxg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Great info, I really appreciate the insight.  Is there a FAQ/recommended 
setup for running pgbench to determine where this might be?  (Is there a 
reason to setup pgbench differently based on the server's cores/memory/etc?)

Sorry if this detracts from the OP's original question.

-AJ

On 3/4/2013 9:36 AM, Scott Marlowe wrote:
> On Mon, Mar 4, 2013 at 7:04 AM, AJ Weber<aweber@comcast.net>  wrote:
>> Apologies for the tangential question, but how would pgpool2 "increase
>> throughput"?  Wouldn't the same number of statements be issued by your
>> application?  It would likely reduce the number of concurrent connections,
>> but that doesn't necessarily equate to "increased throughput".
> This is a pretty common subject.  Most servers have a "peak
> throughput" that occurs at some fixed number of connections.  for
> instance a common throughput graph of pgbench on a server might look
> like this:
>
> conns : tps
> 1 : 200
> 2 : 250
> 4 : 400
> 8 : 750
> 12 : 1200
> 16 : 2000
> 24 : 2200
> 28 : 2100
> 32 : 2000
> 40 : 1800
> 64 : 1200
> 80 : 800
> 100 : 400
>
> So by concentrating your connections to be ~24 you would get maximum
> throughput.  Such a graph is typical for most db servers, just a
> different "sweet spot" where the max throughput for a given number of
> connections. Some servers fall off fast past this number, some just
> slowly drop off.


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