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: AANLkTimpHUYGUpjjR0qdAbgBG=s3CW71VMCnR=E_WO61@mail.gmail.com (view raw or flat)
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.

Possible.

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

> 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
EnterpriseDB: http://www.enterprisedb.com
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-2014 The PostgreSQL Global Development Group