Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 75D92635869 for ; Wed, 18 Mar 2009 19:01:53 -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 04838-05 for ; Wed, 18 Mar 2009 19:01:44 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by mail.postgresql.org (Postfix) with ESMTP id 08218635B5C for ; Wed, 18 Mar 2009 19:01:22 -0300 (ADT) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2IM1Lsb015159 for ; Wed, 18 Mar 2009 22:01:21 GMT MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_8Om2nqD4tG/WPPfMjdn6NA)" Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) id <0KGQ00F000ZI0J00@mail-amer.sun.com> for pgsql-performance@postgresql.org; Wed, 18 Mar 2009 16:01:21 -0600 (MDT) Received: from [129.148.169.151] ([unknown] [129.148.169.151]) by mail-amer.sun.com (Sun Java(tm) System Messaging Server 7.0-5.01 64bit (built Feb 19 2009)) with ESMTPSA id <0KGQ00MVL2HZWG80@mail-amer.sun.com>; Wed, 18 Mar 2009 16:01:12 -0600 (MDT) Date: Wed, 18 Mar 2009 17:57:25 -0400 From: "Jignesh K. Shah" Subject: Re: Proposal of tunable fix for scalability of 8.4 In-reply-to: To: Scott Carey Cc: Gregory Stark , Simon Riggs , Tom Lane , Kevin Grittner , "pgsql-performance@postgresql.org" Message-id: <49C16E45.9020307@sun.com> Organization: Sun Microsystems References: User-Agent: Thunderbird 2.0.0.17 (X11/20081023) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200903/259 X-Sequence-Number: 33181 This is a multi-part message in MIME format. --Boundary_(ID_8Om2nqD4tG/WPPfMjdn6NA) Content-type: text/plain; format=flowed; charset=iso-8859-1 Content-transfer-encoding: 7BIT On 03/18/09 17:16, Scott Carey wrote: > On 3/18/09 4:36 AM, "Gregory Stark" wrote: > > >> "Jignesh K. Shah" writes: >> >> >>> In next couple of weeks I plan to test the patch on a different x64 based >>> system to do a sanity testing on lower number of cores and also try out other >>> workloads ... >>> >> I'm actually more interested in the large number of cores but fewer processes >> and lower max_connections. If you set max_connections to 64 and eliminate the >> wait time you should, in theory, be able to get 100% cpu usage. It would be >> very interesting to track down the contention which is preventing that. >> > > My previous calculation in this thread showed that even at 0 wait time, the > client seems to introduce ~3ms wait time overhead on average. So it takes > close to 128 threads in each test to stop the linear scaling since the > average processing time seems to be about ~3ms. > Either that, or the tests actually are running on a system capable of 128 > threads. > > Nope 64 threads for sure .. Verified it number of times .. -Jignesh >> -- >> Gregory Stark >> EnterpriseDB http://www.enterprisedb.com >> Ask me about EnterpriseDB's PostGIS support! >> >> - >> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-performance >> >> > > > - > Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance > --Boundary_(ID_8Om2nqD4tG/WPPfMjdn6NA) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT

On 03/18/09 17:16, Scott Carey wrote: 
On 3/18/09 4:36 AM, "Gregory Stark" <stark@enterprisedb.com> wrote:

  
"Jignesh K. Shah" <J.K.Shah@Sun.COM> writes:

    
In next couple of weeks I plan to test the patch on a different x64 based
system to do a sanity testing on lower number of cores and also try out other
workloads ...
      
I'm actually more interested in the large number of cores but fewer processes
and lower max_connections. If you set max_connections to 64 and eliminate the
wait time you should, in theory, be able to get 100% cpu usage. It would be
very interesting to track down the contention which is preventing that.
    

My previous calculation in this thread showed that even at 0 wait time, the
client seems to introduce ~3ms wait time overhead on average.  So it takes
close to 128 threads in each test to stop the linear scaling since the
average processing time seems to be about ~3ms.
Either that, or the tests actually are running on a system capable of 128
threads.

Nope 64 threads for sure .. Verified it number of times ..

-Jignesh


  

    
--
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com
  Ask me about EnterpriseDB's PostGIS support!

-
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

    

  

  


-
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
  






--Boundary_(ID_8Om2nqD4tG/WPPfMjdn6NA)--