From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tatsuo Ishii <ishii@sraoss.co.jp>
Cc: Robert.Lor@Sun.COM
Cc: pgsql-hackers@postgresql.org
Cc: pgsql-performance@postgresql.org
Subject: Re: Sun Donated a Sun Fire T2000 to the PostgreSQL
Date: Thu, 20 Jul 2006 15:01:58 -0400
Message-ID: <8669.1153422118@sss.pgh.pa.us> (raw)
In-Reply-To: <20060713.180234.45872055.t-ishii@sraoss.co.jp>
References: <20060617.101521.95879771.t-ishii@sraoss.co.jp>
<10226.1150511655@sss.pgh.pa.us>
<20060617.111838.39487910.t-ishii@sraoss.co.jp>
<20060713.180234.45872055.t-ishii@sraoss.co.jp>
Tatsuo Ishii <ishii@sraoss.co.jp> writes:
>>> 18% in s_lock is definitely bad :-(. Were you able to determine which
>>> LWLock(s) are accounting for the contention?
> Sorry for the delay. Finally I got the oprofile data. It's
> huge(34MB). If you are interested, I can put somewhere. Please let me
> know.
I finally got a chance to look at this, and it seems clear that all the
traffic is on the BufMappingLock. This is essentially the same problem
we were discussing with respect to Gavin Hamill's report of poor
performance on an 8-way IBM PPC64 box (see hackers archives around
2006-04-21). If your database is fully cached in shared buffers, then
you can do a whole lot of buffer accesses per unit time, and even though
all the BufMappingLock acquisitions are in shared-LWLock mode, the
LWLock's spinlock ends up being heavily contended on an SMP box.
It's likely that CVS HEAD would show somewhat better performance because
of the btree change to cache local copies of index metapages (which
eliminates a fair fraction of buffer accesses, at least in Gavin's test
case). Getting much further than that seems to require partitioning
the buffer mapping table. The last discussion stalled on my concerns
about unpredictable shared memory usage, but I have some ideas on that
which I'll post separately. In the meantime, thanks for sending along
the oprofile data!
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, ishii@sraoss.co.jp, Robert.Lor@Sun.COM, pgsql-hackers@postgresql.org
Subject: Re: Sun Donated a Sun Fire T2000 to the PostgreSQL
In-Reply-To: <8669.1153422118@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox