Re: postgres processes spending most of their time in the kernel - Mailing list pgsql-general

From Tom Lane
Subject Re: postgres processes spending most of their time in the kernel
Date
Msg-id 14880.1009573808@sss.pgh.pa.us
Whole thread Raw
In response to Re: postgres processes spending most of their time in the  ("Jeffrey W. Baker" <jwbaker@acm.org>)
Responses Re: postgres processes spending most of their time in the
List pgsql-general
"Jeffrey W. Baker" <jwbaker@acm.org> writes:
> On Fri, 28 Dec 2001, Tom Lane wrote:
>> Hmm, those look perfectly normal, except one would like to think it's
>> the exception not the rule to be blocking on LWLocks.

> Well, let's don't get too far off track.  The problem, I think, is using
> SysV semaphores instead of CPU-specific test-and-set locking.

No, I've abandoned that theory.  You've shown us half a dozen backtraces
now, and they all are coming from LWLock acquire/release, not spinlock
acquire/release.  If you were using SysV semaphores for spinlocks then
I'd expect to see a lot of traces leading back to spin.c.

> I think it's pretty basic.  It used to run right quickly before I moved to
> 7.2beta4.  My application machine saw loads of 25+, now it only sees loads
> of about 3.  Postgres is throttling it.

Hmm.  And what was your actual *throughput*?  The backtraces you've
shown us all correspond to places where 7.1 would have busy-waited
rather than blocking on a semaphore.  Reduction of nominal CPU load
is exactly what I'd expect, and is not in itself bad.  The real question
is how many transactions can you process per second.

            regards, tom lane

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: postgres processes spending most of their time in the kernel
Next
From: "Jeffrey W. Baker"
Date:
Subject: Re: postgres processes spending most of their time in the