"Jeffrey W. Baker" <jwbaker@acm.org> writes:
>> The backtraces you've shown us all correspond to places where 7.1
>> would have busy-waited rather than blocking on a semaphore.
> But the behavior seems to me to be more like busy-waiting than blocking on
> locks. For example, both of my CPUs are now pegged whenever the database
> is busy, and I never used to see tens of thousands of contexts switches
> per second. I also never used to spend half of my CPU time in the kernel,
> but now I do.
[ scratches head ... ] Well, the LWLock stuff is new code, and it's not
out of the question that there's a bug in it. I can't see where though,
and I don't have enough info to proceed further.
We need to understand what the dynamic behavior is in your situation.
Can you poke into it further, or perhaps grant access to your machine
to someone who can?
One thing that would be quite useful is a more-detailed strace that
would let us determine whether each semop is a lock or unlock. Can you
get strace to record the user-space PC of the semop() caller? If no
joy there, maybe beefing up the LWDEBUG log printouts would produce
a useful trace.
regards, tom lane