Re: testing ProcArrayLock patches - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: testing ProcArrayLock patches
Date
Msg-id 4EC645700200002500043233@gw.wicourts.gov
Whole thread Raw
In response to Re: testing ProcArrayLock patches  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: testing ProcArrayLock patches
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> wrote:
> Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote:
>>> Then again, is this a regular pgbench test or is this
>>> SELECT-only?
>>
>> SELECT-only
> 
> Ah, OK.  I would not expect flexlocks to help with that; Pavan's
> patch might, though.
OK.  Sorry for misunderstanding that.  I haven't gotten around to a
deep reading of the patch yet.  :-(  I based this on the test script
you posted here (with slight modifications for my preferred
directory structures):
http://archives.postgresql.org/pgsql-hackers/2011-10/msg00605.php
If I just drop the -S switch will I have a good test, or are there
other adjustments I should make (besides increasing checkpoint
segments)?  (Well, for the SELECT-only test I didn't bother putting
pg_xlog on a separate RAID 10 on it's own BBU controller as we
normally would for this machine, I'll cover that, too.)
> It doesn't make any sense for PostgreSQL master to be using only
> 50% of the CPU and leaving the rest idle on a lots-of-clients
> SELECT-only test.  That could easily happen on 9.1, but my lock
> manager changes eliminated the only place where anything gets put
> to sleep in that path (except for the emergency sleeps done by
> s_lock, when a spinlock is really badly contended).  So I'm
> confused by these results. Are we sure that the processes are
> being scheduled across all 32 physical cores?
I think so.  My take was that it was showing 32 of 64 *threads*
active -- the hyperthreading funkiness.  Is there something in
particular you'd like me to check?
> At any rate, I do think it's likely that you're being bitten by
> spinlock contention, but we'd need to do some legwork to verify
> that and work out the details.  Any chance you can run oprofile
> (on either branch, don't really care) against the 32 client test
> and post the results?  If it turns out s_lock is at the top of the
> heap, I can put together a patch to help figure out which spinlock
> is the culprit.
oprofile isn't installed on this machine.  I'll take care of that
and post results when I can.
-Kevin



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: proposal: better support for debugging of overloaded functions
Next
From: Robert Haas
Date:
Subject: Re: testing ProcArrayLock patches