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

Re: Performance under contention

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jignesh Shah <jkshah(at)gmail(dot)com>, Ivan Voras <ivoras(at)freebsd(dot)org>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Performance under contention
Date: 2010-12-07 18:09:08
Message-ID: (view raw or whole thread)
Lists: pgsql-performance
On Tue, Dec 7, 2010 at 12:50 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> I wonder if it would be possible to have a very short critical section
>> where we grab the partition lock, acquire the heavyweight lock, and
>> release the partition lock; and then only as a second step record (in
>> the form of a PROCLOCK) the fact that we got it.
> [ confused... ]  Exactly what do you suppose "acquire the lock" would
> be represented as, if not "create a PROCLOCK entry attached to it"?

Update the "granted" array and, if necessary, the grantMask.

> In any case, I think this is another example of not understanding where
> the costs really are.


> As far as I can tell, on modern MP systems much
> of the elapsed time in these operations comes from acquiring exclusive
> access to shared-memory cache lines.  Reducing the number of changes you
> have to make within a small area of shared memory won't save much, once
> you've paid for the first one.

Seems reasonable.

> Changing structures that aren't heavily
> contended (such as a proc's list of its own locks) doesn't cost much at
> all.

I'm not sure where you're getting the idea that a proc's list of its
own locks isn't heavily contended.   That could be true, but it isn't
obvious to me.  We allocate PROCLOCK structures out of a shared hash
table while holding the lock manager partition lock, and we add every
lock to a queue associated with the PROC and a second queue associated
with the LOCK.  So if two processes acquire an AccessShareLock on the
same table, both the LOCK object and at least the SHM_QUEUE portions
of each PROCLOCK are shared, and those aren't necessarily nearby in

> One thing that might be interesting, but that I don't know how to attack
> in a reasonably machine-independent way, is to try to ensure that shared
> and local data structures don't accidentally overlap within cache lines.
> When they do, you pay for fighting the cache line away from another
> processor even when there's no real need.

I'd be sort of surprised if this is a problem - as I understand it,
cache lines are small, contiguous chunks, and surely the heap and the
shared memory segment are mapped into different portions of the
address space...

Robert Haas
The Enterprise PostgreSQL Company

In response to

pgsql-performance by date

Next:From: Robert HaasDate: 2010-12-07 18:10:54
Subject: Re: Performance under contention
Previous:From: Ivan VorasDate: 2010-12-07 18:08:06
Subject: Re: Performance under contention

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