Received: from localhost (unknown [200.46.208.211])
	by mail.postgresql.org (Postfix) with ESMTP id 4752363281D
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Fri, 13 Mar 2009 14:48:58 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024)
	with ESMTP id 39058-07
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Fri, 13 Mar 2009 14:48:47 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from EXHUB018-3.exch018.msoutlookonline.net
	(exhub018-3.exch018.msoutlookonline.net [64.78.17.18])
	by mail.postgresql.org (Postfix) with ESMTP id D140E6331C7
	for <pgsql-performance@postgresql.org>;
	Fri, 13 Mar 2009 14:48:45 -0300 (ADT)
Received: from EXVMBX018-1.exch018.msoutlookonline.net ([64.78.17.47]) by
	EXHUB018-3.exch018.msoutlookonline.net ([64.78.17.18]) with mapi;
	Fri, 13 Mar 2009 10:48:40 -0700
From: Scott Carey <scott@richrelevance.com>
To: Scott Carey <scott@richrelevance.com>, "Jignesh K. Shah"
	<J.K.Shah@Sun.COM>, "pgsql-performance@postgresql.org"
	<pgsql-performance@postgresql.org>
Date: Fri, 13 Mar 2009 10:48:38 -0700
Subject: Re: Proposal of tunable fix for scalability of 8.4
Thread-Topic: [PERFORM] Proposal of tunable fix for scalability of 8.4
Thread-Index: Acmj+t5hYaY0hcpbSYORK8uKw4PHRAABnIoMAACn8Fg=
Message-ID: <C5DFEA86.342D%scott@richrelevance.com>
In-Reply-To: <C5DFE61F.3426%scott@richrelevance.com>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative;
	boundary="_000_C5DFEA86342Dscottrichrelevancecom_"
MIME-Version: 1.0
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0.001 tagged_above=0 required=5 tests=AWL=-0.000,
	HTML_MESSAGE=0.001
X-Spam-Level: 
X-Archive-Number: 200903/171
X-Sequence-Number: 33093

--_000_C5DFEA86342Dscottrichrelevancecom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

On 3/13/09 10:29 AM, "Scott Carey" <scott@richrelevance.com> wrote:


-----------------
Now, with 0ms delay, no threading change:
Throughput is 136000/min @184 users, response time 13ms.  Response time has=
 not jumped too drastically yet, but linear performance increases stopped a=
t about 130 users or so. ProcArrayLock busy, very busy.  CPU: 35% user, 11%=
 system, 54% idle

With 0ms delay, and lock modification 2 (wake some, but not all)
Throughput is 161000/min @328 users, response time 28ms.  At 184 users as b=
efore the change, throughput is 147000/min with response time 0.12ms.  Perf=
ormance scales linearly to 144 users, then slows down and slightly increase=
s after that with more concurrency.
Throughput increase is between 15% and 25%.


Forgot some data:  with the second test above, CPU: 48% user, 18% sys, 35% =
idle.   CPU increased from 46% used in the first test to 65% used, the corr=
esponding throughput increase was not as large, but that is expected on an =
8-threads per core server since memory bandwidth and cache resources at a m=
inimum are shared and only trivial tasks can scale 100%.

Based on the above, I would guess that attaining closer to 100% utilization=
 (its hard to get past 90% with that many cores no matter what), will proba=
blyl give another 10 to 15% improvement at most, to maybe 180000/min throug=
hput.

Its also rather interesting that the 2000 connection case with wait times g=
ets 170000/min throughput and beats the 328 users with 0 delay result above=
.  I suspect the 'wake all' version is just faster.  I would love to see a =
'wake all shared, leave exclusives at front of queue' version, since that w=
ould not allow lock starvation.

--_000_C5DFEA86342Dscottrichrelevancecom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [PERFORM] Proposal of tunable fix for scalability of 8.4</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:=
11pt'>On 3/13/09 10:29 AM, &quot;Scott Carey&quot; &lt;<a href=3D"scott@ric=
hrelevance.com">scott@richrelevance.com</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'><BR>
-----------------<BR>
Now, with 0ms delay, no threading change:<BR>
Throughput is 136000/min @184 users, response time 13ms. &nbsp;Response tim=
e has not jumped too drastically yet, but linear performance increases stop=
ped at about 130 users or so. ProcArrayLock busy, very busy. &nbsp;CPU: 35%=
 user, 11% system, 54% idle<BR>
<BR>
With 0ms delay, and lock modification 2 (wake some, but not all)<BR>
Throughput is 161000/min @328 users, response time 28ms. &nbsp;At 184 users=
 as before the change, throughput is 147000/min with response time 0.12ms. =
&nbsp;Performance scales linearly to 144 users, then slows down and slightl=
y increases after that with more concurrency.<BR>
Throughput increase is between 15% and 25%. <BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'><BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial=
"><SPAN STYLE=3D'font-size:11pt'><BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial=
"><SPAN STYLE=3D'font-size:11pt'>Forgot some data: &nbsp;with the second te=
st above, CPU: 48% user, 18% sys, 35% idle. &nbsp;&nbsp;CPU increased from =
46% used in the first test to 65% used, the corresponding throughput increa=
se was not as large, but that is expected on an 8-threads per core server s=
ince memory bandwidth and cache resources at a minimum are shared and only =
trivial tasks can scale 100%.<BR>
<BR>
Based on the above, I would guess that attaining closer to 100% utilization=
 (its hard to get past 90% with that many cores no matter what), will proba=
blyl give another 10 to 15% improvement at most, to maybe 180000/min throug=
hput.<BR>
<BR>
Its also rather interesting that the 2000 connection case with wait times g=
ets 170000/min throughput and beats the 328 users with 0 delay result above=
. &nbsp;I suspect the &#8216;wake all&#8217; version is just faster. &nbsp;=
I would love to see a &#8216;wake all shared, leave exclusives at front of =
queue&#8217; version, since that would not allow lock starvation.</SPAN></F=
ONT>
</BODY>
</HTML>


--_000_C5DFEA86342Dscottrichrelevancecom_--