Обсуждение: Lock contention (was Re: [PATCHES] update i386 spinlock for hyperthreading)

Manfred Spraul <manfred@colorfullife.com> writes:
> Mark ran a DBT-2 testrun with the attached statistics patch applied: It 
> collects stats about all lightweight locks and dumps them during 
> shutdown. The hottest locks are

> Lock                  Acquire    %contention     sleep calls
> 8(WALInsertLock)      8679205       0.030410          263934
> 5(SInvalLock)        68396470       0.001298           88812
> 1(LockMgrLock)       64089418       0.079783         5113215
> 0(BufMgrLock)       246307425       0.120293        29629089

Okay, that more or less squares with my gut feelings about the system.
Good to have some proof.

> I remember there were patches that tried other algorithms instead of the 
> simple LRU for the buffer manager. Has anyone tried to change the 
> locking of the buffer manager?

LRU etc have nothing to do with this.  The majority of trips into the
buffer manager are for ReadBuffer/ReleaseBuffer.  What we need is to
figure a way for those operations to use finer-grain locks so they don't
contend so much.  However, given that they need to access and possibly
modify global structures (the buffer lookup hashtable and free list),
it's not obvious how to do it.  If we could think of a way to divide
those structures into separately lockable portions, we might get somewhere.

> The effect of padding the lightweight locks to a full cacheline appears 
> to be negligable:

Good, that squares with what the Linux kernel people seem to think.
        regards, tom lane

Tom Lane <tgl@sss.pgh.pa.us> writes:
> LRU etc have nothing to do with this.  The majority of trips into the
> buffer manager are for ReadBuffer/ReleaseBuffer.  What we need is to
> figure a way for those operations to use finer-grain locks so they don't
> contend so much.

I reimplemented much of bufmgr.c over the holidays, with the goal of
reducing the contention for the BufMgrLock as well as fixing some
other less important problems. Where possible, operations that only
effect the state of a single buffer now only need to acquire a
per-buffer "meta data lock". I haven't done any benchmarking yet, but
this should hopefully improve concurrent performance. The patch isn't
quite finished yet, but I'll post it to the list in a few days once
I've had a chance to wrap up a few loose ends.

-Neil