Skip site navigation (1) Skip section navigation (2)

Re: sinval contention reduction

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: sinval contention reduction
Date: 2008-01-26 09:38:48
Message-ID: 1201340328.4257.578.camel@ebony.site (view raw or flat)
Thread:
Lists: pgsql-patches
On Fri, 2008-01-25 at 19:02 -0500, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > Patch to reduce the contention on SInvalLock, as discussed here:
> > http://archives.postgresql.org/pgsql-hackers/2007-09/msg00501.php
> > and
> > http://archives.postgresql.org/pgsql-performance/2008-01/msg00023.php
> 
> > For discussion.
> 
> This seems large, complex, and untested (I note in particular a
> guaranteed-to-fail Assert).  

Yes, its for discussion. How would you describe such a patch in the
future? I want to be able to differentiate patch status. There's no
point polishing it before the discussion.

> I'm also wondering if it will help much,
> since unless the system is already in trouble, the normal case will be
> that all backends have absorbed all messages and so they'll all see
> stateP->nextMsgNum == segP->minMsgNum when they first respond to a
> signal.  

Agreed, that's why its not the only condition.

In the patch, the message queue is normally cleaned when an insert gets
past 50% of queue length, then again at 56%, 62% and 68%. If that
doesn't help then we hit the PM signal at 70% as before. We don't
attempt to clean the queue after every round of messages by each
backend, which causes huge contention as we know.

We only clean the queue if a long run of messages is read by the oldest
message reader, so when stateP->nextMsgNum == segP->minMsgNum && number
of messages read > 25% of queue. So that is only performed by a backend
waking up to find it is behind, such as would happen if a PM signal had
been issued.

> Do you have any evidence for performance improvement?

ISTM that it would only be worth testing when we had a rough agreement
that we had found a reasonable approach.

-- 
  Simon Riggs
  2ndQuadrant  http://www.2ndQuadrant.com


In response to

Responses

pgsql-patches by date

Next:From: Pavel StehuleDate: 2008-01-26 14:50:52
Subject: WIP: variadic function, named params
Previous:From: Tom LaneDate: 2008-01-26 00:02:36
Subject: Re: sinval contention reduction

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group