MIME-version: 1.0
Content-type: multipart/alternative;
	boundary="Boundary_(ID_eVXC4WqioCX0u/qhs9KihQ)"
Date: Thu, 12 Mar 2009 10:57:04 -0400
From: "Jignesh K. Shah" <J.K.Shah@Sun.COM>
Subject: Re: Proposal of tunable fix for scalability of 8.4
In-reply-to: <C5DDBB25.3333%scott@richrelevance.com>
To: Scott Carey <scott@richrelevance.com>
Cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>,
	"pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Message-id: <49B922C0.6050700@sun.com>
Organization: Sun Microsystems
References: <C5DDBB25.3333%scott@richrelevance.com>
User-Agent: Thunderbird 2.0.0.17 (X11/20081023)

This is a multi-part message in MIME format.

--Boundary_(ID_eVXC4WqioCX0u/qhs9KihQ)
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT


On 03/11/09 22:01, Scott Carey wrote:
> On 3/11/09 3:27 PM, "Kevin Grittner" <Kevin.Grittner@wicourts.gov> wrote:
>
>
>     I'm a lot more interested in what's happening between 60 and 180 than
>     over 1000, personally.  If there was a RAID involved, I'd put it down
>     to better use of the numerous spindles, but when it's all in RAM it
>     makes no sense.
>
> If there is enough lock contention and a common lock case is a short 
> lived shared lock, it makes perfect sense sense.  Fewer readers are 
> blocked waiting on writers at any given time.  Readers can 'cut' in 
> line ahead of writers within a certain scope (only up to the number 
> waiting at the time a shared lock is at the head of the queue). 
>  Essentially this clumps up shared and exclusive locks into larger 
> streaks, and allows for higher shared lock throughput.  
> Exclusive locks may be delayed, but will NOT be starved, since on the 
> next iteration, a streak of exclusive locks will occur first in the 
> list and they will all process before any more shared locks can go.
>
> This will even help in on a single CPU system if it is read dominated, 
> lowering read latency and slightly increasing write latency.
>
> If you want to make this more fair, instead of freeing all shared 
> locks, limit the count to some number, such as the number of CPU 
> cores.  Perhaps rather than wake-up-all-waiters=true, the parameter 
> can be an integer representing 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 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 gets a lock which is often the case when you say 
wake up only 1 waiter and hope that the process is on the CPU (which in 
my case it is 64 processes) and it is able to acquire the lock.. The 
probability of acquiring the lock within 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 CPU  and acquire the 
lock. That way the period where nobody has a lock is reduced and that 
helps to cut out "artifact"  idle time on the system.


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


--Boundary_(ID_eVXC4WqioCX0u/qhs9KihQ)
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: 7BIT

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
On 03/11/09 22:01, Scott Carey wrote:
<blockquote cite="mid:C5DDBB25.3333%25scott@richrelevance.com"
 type="cite">
  <meta http-equiv="Context-Type"
 content="text/html; charset=iso-8859-1">
  <title>Re: [PERFORM] Proposal of tunable fix for scalability of 8.4</title>
  <span>On 3/11/09 3:27 PM, "Kevin Grittner" &lt;<a
 moz-do-not-send="true" href="Kevin.Grittner@wicourts.gov">Kevin.Grittner@wicourts.gov</a>&gt;
wrote:<br>
  </span>
  <blockquote> <span><br>
I'm a lot more interested in what's happening between 60 and 180 than<br>
over 1000, personally. &nbsp;If there was a RAID involved, I'd put it down<br>
to better use of the numerous spindles, but when it's all in RAM it<br>
makes no sense.<br>
    <br>
    </span> </blockquote>
  <span>If there is enough lock contention and a common lock case is a
short lived shared lock, it makes perfect sense sense. &nbsp;Fewer readers
are blocked waiting on writers at any given time. &nbsp;Readers can &#8216;cut&#8217; in
line ahead of writers within a certain scope (only up to the number
waiting at the time a shared lock is at the head of the queue).
&nbsp;Essentially this clumps up shared and exclusive locks into larger
streaks, and allows for higher shared lock throughput. &nbsp;<br>
Exclusive locks may be delayed, but will NOT be starved, since on the
next iteration, a streak of exclusive locks will occur first in the
list and they will all process before any more shared locks can go.<br>
  <br>
This will even help in on a single CPU system if it is read dominated,
lowering read latency and slightly increasing write latency.<br>
  <br>
If you want to make this more fair, instead of freeing all shared
locks, limit the count to some number, such as the number of CPU cores.
&nbsp;Perhaps rather than wake-up-all-waiters=true, the parameter can be an
integer representing how many shared locks can be freed at once if an
exclusive lock is encountered. <br>
  </span>
  <blockquote><span><br>
    </span> </blockquote>
</blockquote>
Well I am waking up not just shared but shared and exclusives.. However
i like your idea of waking up the next N waiters where N matches the
number of cpus available.&nbsp; 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&nbsp; immediately 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 process is on the CPU
(which in my case it is 64 processes) and it is able to acquire the
lock.. The probability of acquiring the lock within the next few cycles
is much less for only 1 waiter&nbsp; than giving chance to 64 such
processes&nbsp; and then let them fight based on who is already on CPU&nbsp; and
acquire the lock. That way the period where nobody has a lock is
reduced and that helps to cut out "artifact"&nbsp; idle time on the system.<br>
<br>
<br>
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.<br>
<br>
<br>
-Jignesh<br>
<br>
</body>
</html>

--Boundary_(ID_eVXC4WqioCX0u/qhs9KihQ)--