From: Scott Carey <scott@richrelevance.com>
To: Gregory Stark <stark@enterprisedb.com>
To: Grzegorz Jaśkiewicz <gryzman@gmail.com>
Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Cc: Jignesh K. Shah <J.K.Shah@sun.com>
Subject: Re: Proposal of tunable fix for scalability of 8.4
Date: Thu, 12 Mar 2009 11:08:44 -0700
Message-ID: <C5DE9DBC.3387%scott@richrelevance.com> (raw)
In-Reply-To: <87k56u652a.fsf@oxford.xeocode.com>
On 3/12/09 10:09 AM, "Gregory Stark" <stark@enterprisedb.com> wrote:
Ram-resident use cases are entirely valid and worth testing, but in those use
cases you would want to have about as many processes as you have processes.
Within a factor of two or so, yes. However, where in his results does it show that there are 1000 active postgres connections? What if the test script is the most valid type: emulating application compute and sleep time between requests?
What it is showing is “Users”. We don’t know the relationship between those and active postgres connections. Your contention is ONLY valid for active postgres processes.
Yes, the test could be invalid if it is artificially making all users bang up on the same locks by for example, having them all access the same rows. However, if this was what explains the results around the user count being about equal to CPU threads, then the throughput would have stopped growing around where the user count got near the CPU threads, not after a couple thousand.
The ‘fingerprint’ of this load test — linear scaling up to a point, then a peak and dropoff — is one of a test with paced users not one with artificial locking affecting results at low user counts. More data would help, but artificial lock contention with low user count would have shown up at low user count, not after 1000 users. There are some difficult to manipulate ways to fake this out (which is why CPU% and context switch rate data would help). This is most likely a ‘paced user’ profile.
The use case where having larger number of connections than processors makes
sense is when they're blocked on disk i/o (or network i/o or whatever else
other than cpu).
Um, or are idle in a connection pool for 100ms. There is no such thing as a perfectly sized connection pool. And there is nothing wrong with some idle connections.
And as always the question would be whether the code designed for this
misconfigured setup is worth the maintenance effort if it's not helping
properly configured setups.
Now you are just assuming its misconfigured. I’d wager quite a bit it helps properly configured setups too so long as they have lots of hardware threads.
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: scott@richrelevance.com, stark@enterprisedb.com, gryzman@gmail.com, Kevin.Grittner@wicourts.gov, J.K.Shah@sun.com
Subject: Re: Proposal of tunable fix for scalability of 8.4
In-Reply-To: <C5DE9DBC.3387%scott@richrelevance.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