From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Jeffrey W(dot) Baker" <jwbaker(at)acm(dot)org> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: postgres processes spending most of their time in the kernel |
Date: | 2001-12-28 21:10:08 |
Message-ID: | 14880.1009573808@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Jeffrey W. Baker" <jwbaker(at)acm(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jeffrey W. Baker | 2001-12-28 21:42:00 | Re: postgres processes spending most of their time in the |
Previous Message | Jeffrey W. Baker | 2001-12-28 21:00:27 | Re: postgres processes spending most of their time in the |