From: Jignesh K. Shah <J.K.Shah@Sun.COM>
To: Scott Carey <scott@richrelevance.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: Proposal of tunable fix for scalability of 8.4
Date: Fri, 13 Mar 2009 08:38:39 -0400
Message-ID: <49BA53CF.4020702@sun.com> (raw)
In-Reply-To: <C5DEE151.33BA%scott@richrelevance.com>
References: <C5DEE151.33BA%scott@richrelevance.com>
Scott Carey wrote:
> On 3/12/09 11:37 AM, "Jignesh K. Shah" <J.K.Shah@Sun.COM> wrote:
>
>
> And again this is the third time I am saying.. the test users also
> have some latency build up in them which is what generally is
> exploited to get more users than number of CPUS on the system but
> that's the point we want to exploit.. Otherwise if all new users
> begin to do their job with no latency then we would need 6+
> billion cpus to handle all possible users. Typically as an
> administrator (System and database) I can only tweak/control
> latencies within my domain, that is network, disk, cpu's etc and
> those are what I am tweaking and coming to a *Configured*
> environment and now trying to improve lock contentions/waits in
> PostgreSQL so that we have an optimized setup.
>
> 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. Small latency (100ms to 1s) tests are easy to
> make from the zero delay ones, and help expose problems with
> connection count or other forms of ‘non-active’ concurrency. End-user
> realistic delays are app specific, and useful with larger holistic
> load tests (say, through the application interface). Generally,
> running them in this order helps because at each stage you are adding
> complexity. Based on your explanations, you’ve probably done much of
> this so far and your approach sounds solid to me.
> If the first case fails (zero delay, smaller user count), there is no
> way the others will pass.
>
>
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.
-Jignesh
--
Jignesh Shah http://blogs.sun.com/jkshah
The New Sun Microsystems,Inc http://sun.com/postgresql
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: J.K.Shah@Sun.COM, scott@richrelevance.com, tgl@sss.pgh.pa.us, Kevin.Grittner@wicourts.gov
Subject: Re: Proposal of tunable fix for scalability of 8.4
In-Reply-To: <49BA53CF.4020702@sun.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox