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

Re: LWLock Queue Jumping

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: LWLock Queue Jumping
Date: 2009-08-30 06:03:23
Message-ID: 4A9A162B.2090602@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackers
Greg Stark wrote:
> On Fri, Aug 28, 2009 at 8:07 PM, Simon Riggs<simon(at)2ndquadrant(dot)com> wrote:
>> 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?

I don't have any pointers right now, but WALInsertLock does often show
up as a bottleneck in write-intensive benchmarks.

>> 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.
> 
> 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?

That's what I thought. I don't know about the clog/multixact issue, it
doesn't seem like it would be too bad, given how seldom new clog or
multixact pages are written.

The Hot Standby thing has been discussed, but no-one has actually posted
a patch which does the locking correctly, where the ProcArrayLock is
held while the SnapshotData WAL record is inserted. So there is no
evidence that it's actually a problem, we might be making a mountain out
of a molehill. It will have practically no effect on throughput, given
how seldom SnapshotData records are written (once per checkpoint), but
if it causes a significant bump to response times, that might be a problem.

This is a good idea to keep in mind, but right now it feels like a
solution in search of a problem.

-- 
  Heikki Linnakangas
  EnterpriseDB   http://www.enterprisedb.com

In response to

Responses

pgsql-hackers by date

Next:From: Stefan KaltenbrunnerDate: 2009-08-30 09:48:47
Subject: Re: LWLock Queue Jumping
Previous:From: Greg StarkDate: 2009-08-29 23:28:14
Subject: Re: LWLock Queue Jumping

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