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