Re: [PERFORM] Proposal of tunable fix for scalability of 8.4 </TITLE= > </HEAD> <BODY> On 3/12/09 10:53 AM, "Tom Lane" <<a href=3D"tgl@sss.pgh.= pa.us">tgl@sss.pgh.pa.us</a>> wrote: <BLOCKQUOTE>"Kevin Grittner" <<a href=3D"K= evin.Grittner@wicourts.gov">Kevin.Grittner@wicourts.gov</a>> writes: > You misunderstood me. I wasn't addressing the affects of his cha= nge, > but rather the fact that his test shows a linear improvement in TPS up= > to 1000 connections for a 64 thread machine which is dealing entirely<= BR> > with RAM -- no disk access. Where's the bottleneck that allows t= his > to happen? Without understanding that, his results are meaningle= ss. Yeah, that is a really good point. For a CPU-bound test you would ideally expect linear performance improvement up to the point at which number of active threads equals number of CPUs, and flat throughput with more threads. The fact that his results don't look like that should excite deep suspicion that something is wrong somewhere. This does not in itself prove that the idea is wrong, but it does say that there is some major effect happening in this test that we don't understand. Without understanding it, it's impossible to guess whethe= r the proposal is helpful in any other scenario. &nb= sp; regard= s, tom lane </BLOCKQUOTE>Only on the assumption that each thread in= the load test is running in ASAP mode rather than a metered pace.</= FONT> </BODY> </HTML> --_000_C5DE9DF53388scottrichrelevancecom

Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 625E46348D8 for ; Thu, 12 Mar 2009 15:09:49 -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 94507-06 for ; Thu, 12 Mar 2009 15:09:46 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from EXHUB018-2.exch018.msoutlookonline.net (exhub018-2.exch018.msoutlookonline.net [64.78.17.17]) by mail.postgresql.org (Postfix) with ESMTP id E02BE634779 for ; Thu, 12 Mar 2009 15:09:45 -0300 (ADT) Received: from EXVMBX018-1.exch018.msoutlookonline.net ([64.78.17.47]) by EXHUB018-2.exch018.msoutlookonline.net ([64.78.17.17]) with mapi; Thu, 12 Mar 2009 11:09:44 -0700 From: Scott Carey To: Tom Lane , Kevin Grittner CC: "pgsql-performance@postgresql.org" , "Jignesh K. Shah" Date: Thu, 12 Mar 2009 11:09:41 -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: AcmjO2+EWv1oQSC6Rei9e+DNamZwJgAAkcpy Message-ID: In-Reply-To: <11839.1236880397@sss.pgh.pa.us> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C5DE9DF53388scottrichrelevancecom_" 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/134 X-Sequence-Number: 33056 --_000_C5DE9DF53388scottrichrelevancecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 3/12/09 10:53 AM, "Tom Lane" wrote: "Kevin Grittner" writes: > You misunderstood me. I wasn't addressing the affects of his change, > but rather the fact that his test shows a linear improvement in TPS up > to 1000 connections for a 64 thread machine which is dealing entirely > with RAM -- no disk access. Where's the bottleneck that allows this > to happen? Without understanding that, his results are meaningless. Yeah, that is a really good point. For a CPU-bound test you would ideally expect linear performance improvement up to the point at which number of active threads equals number of CPUs, and flat throughput with more threads. The fact that his results don't look like that should excite deep suspicion that something is wrong somewhere. This does not in itself prove that the idea is wrong, but it does say that there is some major effect happening in this test that we don't understand. Without understanding it, it's impossible to guess whether the proposal is helpful in any other scenario. regards, tom lane Only on the assumption that each thread in the load test is running in ASAP= mode rather than a metered pace. --_000_C5DE9DF53388scottrichrelevancecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [PERFORM] Proposal of tunable fix for scalability of 8.4 </TITLE= > </HEAD> <BODY> On 3/12/09 10:53 AM, "Tom Lane" <<a href=3D"tgl@sss.pgh.= pa.us">tgl@sss.pgh.pa.us</a>> wrote: <BLOCKQUOTE>"Kevin Grittner" <<a href=3D"K= evin.Grittner@wicourts.gov">Kevin.Grittner@wicourts.gov</a>> writes: > You misunderstood me. I wasn't addressing the affects of his cha= nge, > but rather the fact that his test shows a linear improvement in TPS up= > to 1000 connections for a 64 thread machine which is dealing entirely<= BR> > with RAM -- no disk access. Where's the bottleneck that allows t= his > to happen? Without understanding that, his results are meaningle= ss. Yeah, that is a really good point. For a CPU-bound test you would ideally expect linear performance improvement up to the point at which number of active threads equals number of CPUs, and flat throughput with more threads. The fact that his results don't look like that should excite deep suspicion that something is wrong somewhere. This does not in itself prove that the idea is wrong, but it does say that there is some major effect happening in this test that we don't understand. Without understanding it, it's impossible to guess whethe= r the proposal is helpful in any other scenario. &nb= sp; regard= s, tom lane </BLOCKQUOTE>Only on the assumption that each thread in= the load test is running in ASAP mode rather than a metered pace.</= FONT> </BODY> </HTML> --_000_C5DE9DF53388scottrichrelevancecom_--