Robert Haas <robertmh...@gmail.com> wrote: > Kevin Grittner <kevin.gritt...@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
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers