Re: futex results with dbt-3

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Manfred Spraul <manfred(at)colorfullife(dot)com>
Cc: neilc(at)samurai(dot)com, markw(at)osdl(dot)org, pgsql-performance(at)postgresql(dot)org
Subject: Re: futex results with dbt-3
Date: 2004-10-25 17:45:28
Message-ID: 21743.1098726328@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Manfred Spraul <manfred(at)colorfullife(dot)com> writes:
> Tom Lane wrote:
>> It could be that I'm all wet and there is no relationship between the
>> cache line thrashing and the seemingly excessive BufMgrLock contention.
>>
> Is it important? The fix is identical in both cases: per-bucket locks
> for the hash table and a buffer aging strategy that doesn't need one
> global lock that must be acquired for every lookup.

Reducing BufMgrLock contention is a good idea, but it's not really my
idea of a fix for this issue. In the absence of a full understanding,
we may be fixing the wrong thing. It's worth remembering that when we
first hit this issue, I made some simple changes that approximately
halved the number of BufMgrLock acquisitions by joining ReleaseBuffer
and ReadBuffer calls into ReleaseAndReadBuffer in all the places in the
test case's loop. This made essentially no change in the CS storm
behavior :-(. So I do not know how much contention we have to get rid
of to get the problem to go away, or even whether this is the right path
to take.

(I am unconvinced that either of those specific suggestions is The Right
Way to break up the bufmgrlock, either, but that's a different thread.)

regards, tom lane

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Anjan Dave 2004-10-25 20:53:23 can't handle large number of INSERT/UPDATEs
Previous Message Manfred Spraul 2004-10-25 17:30:38 Re: futex results with dbt-3