Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 25E136335E3 for ; Thu, 12 Mar 2009 14:09:38 -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 80003-06 for ; Thu, 12 Mar 2009 14:09:33 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from EXHUB018-1.exch018.msoutlookonline.net (exhub018-1.exch018.msoutlookonline.net [64.78.17.16]) by mail.postgresql.org (Postfix) with ESMTP id 213EB633155 for ; Thu, 12 Mar 2009 14:09:34 -0300 (ADT) Received: from EXVMBX018-1.exch018.msoutlookonline.net ([64.78.17.47]) by EXHUB018-1.exch018.msoutlookonline.net ([64.78.17.16]) with mapi; Thu, 12 Mar 2009 10:09:33 -0700 From: Scott Carey To: "Jignesh K. Shah" CC: Kevin Grittner , "pgsql-performance@postgresql.org" Date: Thu, 12 Mar 2009 10:09:31 -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: AcmjI147YMdijW5cR/2JBRl9dzSidwAEfC5n Message-ID: In-Reply-To: <49B922C0.6050700@sun.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_C5DE8FDB3376scottrichrelevancecom_" 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/126 X-Sequence-Number: 33048 --_000_C5DE8FDB3376scottrichrelevancecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On 3/12/09 7:57 AM, "Jignesh K. Shah" wrote: On 03/11/09 22:01, Scott Carey wrote: Re: [PERFORM] Proposal of tunable fix for scalability of 8.4 On 3/11/09 3:= 27 PM, "Kevin Grittner" wrote: If you want to make this more fair, instead of freeing all shared locks, li= mit the count to some number, such as the number of CPU cores. Perhaps rat= her than wake-up-all-waiters=3Dtrue, the parameter can be an integer repres= enting how many shared locks can be freed at once if an exclusive lock is e= ncountered. Well I am waking up not just shared but shared and exclusives.. However i l= ike your idea of waking up the next N waiters where N matches the number of= cpus available. In my case it is 64 so yes this works well since the idea= being of all the 64 waiters running right now one will be able to lock the= next lock immediately and hence there are no cycles wasted where nobody g= ets a lock which is often the case when you say wake up only 1 waiter and h= ope that the process is on the CPU (which in my case it is 64 processes) an= d it is able to acquire the lock.. The probability of acquiring the lock wi= thin the next few cycles is much less for only 1 waiter than giving chance= to 64 such processes and then let them fight based on who is already on C= PU and acquire the lock. That way the period where nobody has a lock is re= duced and that helps to cut out "artifact" idle time on the system. In that case, there can be some starvation of writers. If all the shareds = are woken up but the exclusives are left in the front of the queued, no sta= rvation can occur. That was a bit of confusion on my part with respect to what the change was = doing. Thanks for clarification. As soon as I get more "cycles" I will try variations of it but it would hel= p if others can try it out in their own environments to see if it helps the= ir instances. -Jignesh --_000_C5DE8FDB3376scottrichrelevancecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [PERFORM] Proposal of tunable fix for scalability of 8.4 On 3/12/09 7:57 AM, "Jignesh K. Shah" <J.K.Shah@Sun.COM> wrote:



On 03/11/09 22:01, Scott Carey wrote:
 Re: [PERFORM] Proposal of tunable fi= x for scalability of 8.4 On 3/11/09 3:27 PM, "Kevin Grittner" <= ;Kevin.Grittner@wicourts.gov>= ; wrote:

 
If you want to make this more fair, instead of freeing all shared locks, li= mit the count to some number, such as the number of CPU cores.  Perhap= s rather than wake-up-all-waiters=3Dtrue, the parameter can be an integer r= epresenting how many shared locks can be freed at once if an exclusive lock= is encountered.
  

  
Well I am waking up not just = shared but shared and exclusives.. However i like your idea of waking up th= e next N waiters where N matches the number of cpus available.  In my = case it is 64 so yes this works well since the idea being of all the 64 wai= ters running right now one will be able to lock the next lock  immedia= tely and hence there are no cycles wasted where nobody gets a lock which is= often the case when you say wake up only 1 waiter and hope that the proces= s is on the CPU (which in my case it is 64 processes) and it is able to acq= uire the lock.. The probability of acquiring the lock within the next few c= ycles is much less for only 1 waiter  than giving chance to 64 such pr= ocesses  and then let them fight based on who is already on CPU  = and acquire the lock. That way the period where nobody has a lock is reduce= d and that helps to cut out "artifact"  idle time on the sys= tem.




As soon as I get more "cycles" I will try variations of it but it= would help if others can try it out in their own environments to see if it= helps their instances.


-Jignesh


 --_000_C5DE8FDB3376scottrichrelevancecom_--