---------- Forwarded message ----------
From: Greg Stark <gsstark@mit.edu>
To: Simon Riggs <simon@2ndquadrant.com>
Date: Sun, 30 Aug 2009 00:28:14 +0100
Subject: Re: LWLock Queue Jumping
On Fri, Aug 28, 2009 at 8:07 PM, Simon Riggswrote:
WALInsertLock is heavily contended and likely always will be even if we
apply some of the planned fixes.
I've lost any earlier messages, could you resend the raw data on which
this is based?
Some callers of WALInsertLock are more important than others

* Writing new Clog or Multixact pages (serialized by ClogControlLock)
* For Hot Standby, writing SnapshotData (serialized by ProcArrayLock)

In these cases it seems like we can skip straight to the front of the
WALInsertLock queue without problem.
How does re-ordering reduce the contention?


If you hold one contended lock while waiting in a FIFO for another contended
lock, you just made the first lock that much more contended. Jumping queue
on the WALInsertLock
probably does not reduce contention on WALInsertLock, but does prevent that
contention from introducing derivative contention on other locks which are
already held while waiting (ProcArrayLock and ClogControlLock)


We reorder shared lockers
ahead of exclusive lockers because they can all hold the lock at

We don't explicitly reorder shared lockers ahead of exclusive lockers. "The
reordering" works for either case. A holder of a shared lock who drops the
lock but then grabs it again before the awakened exclusive waiter has to
chance to grab it is "reordered", but so is the exclusive holder who drops a
lock and then grabs it again before any of the awakened shared waiters have
had a chance to grab it. The primary point is not to reorder the locks, but
to avoid excessive context switches.


the
same time so we can reduce the amount of time the lock is held.

Reordering some exclusive lockers ahead of other exclusive lockers
won't reduce the amount of time the lock is held at all. Are you
saying the reason to do it is to reduce time spent waiting on this
lock while holding other critical locks? Do we have tools to measure
how long is being spent waiting on one lock while holding another lock
so we can see if there's a problem and whether this helps?

I don't know of any formal tools for that. I just add elog statements at
strategic places and then mine the logfile. You have to be careful that the
time spent doing the logging doesn't distort the timings too much, but I
usually haven't found that to be a problem. I've toyed with changes to
LWLOCK_STATS to help, but you have to focus on a few specific locks or else
the overhead is generally too high, and if you are interested in only a
handful of locks adding elog statements seems easier. But I was looking in
other areas of the code, not this specific area under discussion.

Jeff

Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedAug 30, '09 at 5:09p
activeAug 30, '09 at 5:09p
posts1
users1
websitepostgresql.org...
irc#postgresql

1 user in discussion

Jeff Janes: 1 post

People

Translate

site design / logo © 2022 Grokbase