MIME-version: 1.0
Content-type: multipart/alternative;
	boundary="Boundary_(ID_5lhTqzQOv9cO0kD5jdRsjw)"
Date: Thu, 12 Mar 2009 15:22:09 -0400
From: "Jignesh K. Shah" <J.K.Shah@Sun.COM>
Subject: Re: Proposal of tunable fix for scalability of 8.4
In-reply-to: <20090312191020.GB29971@alvh.no-ip.org>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Scott Carey <scott@richrelevance.com>,
	Kevin Grittner <Kevin.Grittner@wicourts.gov>,
	"pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Message-id: <49B960E1.6070101@sun.com>
Organization: Sun Microsystems
References: <C5DE96C9.337E%scott@richrelevance.com>
	<12916.1236882481@sss.pgh.pa.us>
	<20090312191020.GB29971@alvh.no-ip.org>
User-Agent: Thunderbird 2.0.0.17 (X11/20081023)

This is a multi-part message in MIME format.

--Boundary_(ID_5lhTqzQOv9cO0kD5jdRsjw)
Content-type: text/plain; format=flowed; charset=us-ascii
Content-transfer-encoding: 7BIT


On 03/12/09 15:10, Alvaro Herrera wrote:
> 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 CPU bound / RAM bound case, as concurrency increases you look for the throughput trend, the %CPU use trend and the context switch rate trend.  More information would be useful but the test is validated by the evidence that it is held up by 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 ...
>   
short of doing select * from pg_stat_activity and removing the IDLE 
entries, any other clean way to get that information. If there is no 
other latency then active backends should be active users * 10ms/200ms 
or activeusers/20 on average. However the number is still lower than 
that since active user can still be waiting for locks which can be 
either on CPU (spin) or sleeping (proven by increase in average response 
time of execution which includes the wait).

Also till date I am primarily more interested in active backends which 
are waiting for acquiring the locks since I find making that more 
efficient gives me the biggest return on my buck.. Lower response time 
and higher throughput.

-Jignesh


--Boundary_(ID_5lhTqzQOv9cO0kD5jdRsjw)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=us-ascii" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
On 03/12/09 15:10, Alvaro Herrera wrote:
<blockquote cite="mid:20090312191020.GB29971@alvh.no-ip.org" type="cite">
  <pre wrap="">Tom Lane wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Scott Carey <a class="moz-txt-link-rfc2396E" href="mailto:scott@richrelevance.com">&lt;scott@richrelevance.com&gt;</a> writes:
    </pre>
    <blockquote type="cite">
      <pre wrap="">They are not meaningless.  It is certainly more to understand, but the test is entirely valid without that.  In a CPU bound / RAM bound case, as concurrency increases you look for the throughput trend, the %CPU use trend and the context switch rate trend.  More information would be useful but the test is validated by the evidence that it is held up by lock contention.
      </pre>
    </blockquote>
    <pre wrap="">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.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
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 ...
  </pre>
</blockquote>
short of doing select * from pg_stat_activity and removing the IDLE
entries, any other clean way to get that information.&nbsp; If there is no
other latency then active backends&nbsp; should be active users * 10ms/200ms
or activeusers/20 &nbsp; on average. However the number is still lower than
that since active user can still be waiting for locks which can be
either on CPU (spin) or sleeping (proven by increase in average
response time of execution which includes the wait). <br>
&nbsp;<br>
Also till date I am primarily more interested in active backends which
are waiting for acquiring the locks since I find&nbsp; making that more
efficient gives me the biggest return on my buck.. Lower response time
and higher throughput.<br>
<br>
-Jignesh<br>
<br>
</body>
</html>

--Boundary_(ID_5lhTqzQOv9cO0kD5jdRsjw)--