Re: Proposal of tunable fix for scalability of 8.4 - Mailing list pgsql-performance

From Alvaro Herrera
Subject Re: Proposal of tunable fix for scalability of 8.4
Date
Msg-id 20090312191020.GB29971@alvh.no-ip.org
Whole thread Raw
In response to Re: Proposal of tunable fix for scalability of 8.4  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Proposal of tunable fix for scalability of 8.4
List pgsql-performance
Tom Lane wrote:
> Scott Carey <scott@richrelevance.com> writes:
> > They are not meaningless.  It is certainly more to understand, but the test is entirely valid without that.  In a
CPUbound / RAM bound case, as concurrency increases you look for the throughput trend, the %CPU use trend and the
contextswitch rate trend.  More information would be useful but the test is validated by the evidence that it is held
upby lock contention. 
>
> Er ... *what* evidence?  There might be evidence somewhere that proves
> that, but Jignesh hasn't shown it.  The available data suggests that the
> first-order performance limiter in this test is something else.
> Otherwise it should be possible to max out the performance with a lot
> less than 1000 active backends.

With 200ms of think times as Jignesh just said, 1000 users does not
equate 1000 active backends.  (It's probably closer to 100 backends,
given an avg. response time of ~20ms)

Something that might be useful for him to report is the avg number of
active backends for each data point ...

--
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

pgsql-performance by date:

Previous
From: "Jignesh K. Shah"
Date:
Subject: Re: Proposal of tunable fix for scalability of 8.4
Next
From: "Kevin Grittner"
Date:
Subject: Re: Proposal of tunable fix for scalability of 8.4