MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Date: Fri, 13 Mar 2009 09:36:53 -0400
From: "Jignesh K. Shah" <J.K.Shah@Sun.COM>
Subject: Re: Proposal of tunable fix for scalability of 8.4
In-reply-to: <871vt1609r.fsf@oxford.xeocode.com>
To: Gregory Stark <stark@enterprisedb.com>
Cc: Scott Carey <scott@richrelevance.com>, Tom Lane <tgl@sss.pgh.pa.us>,
	Kevin Grittner <Kevin.Grittner@wicourts.gov>,
	"pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Message-id: <49BA6175.4060809@sun.com>
References: <C5DEE151.33BA%scott@richrelevance.com> <49BA53CF.4020702@sun.com>
	<871vt1609r.fsf@oxford.xeocode.com>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)


Gregory Stark wrote:
> "Jignesh K. Shah" <J.K.Shah@Sun.COM> writes:
>
>   
>> Scott Carey wrote:
>>     
>>> On 3/12/09 11:37 AM, "Jignesh K. Shah" <J.K.Shah@Sun.COM> wrote:
>>>
>>> In general, I suggest that it is useful to run tests with a few different
>>> types of pacing. Zero delay pacing will not have realistic number of
>>> connections, but will expose bottlenecks that are universal, and less
>>> controversial
>>>       
>> I think I have done that before so I can do that again by running the users at
>> 0 think time which will represent a "Connection pool" which is highly utilized"
>> and test how big the connection pool can be before the throughput tanks.. This
>> can be useful for App Servers which sets up connections pools of their own
>> talking with PostgreSQL.
>>     
>
> Keep in mind when you do this that it's not interesting to test a number of
> connections much larger than the number of processors you have. Once the
> system reaches 100% cpu usage it would be a misconfigured connection pooler
> that kept more than that number of connections open.
>
>   

Greg, Unfortuately the problem is that..  I am trying to reach 100% CPU which I cannot and hence I am increasing the user count :-)

-Jignesh