Re: postgres processes spending most of their time in the kernel
От | Tom Lane |
---|---|
Тема | Re: postgres processes spending most of their time in the kernel |
Дата | |
Msg-id | 14880.1009573808@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: postgres processes spending most of their time in the ("Jeffrey W. Baker" <jwbaker@acm.org>) |
Ответы |
Re: postgres processes spending most of their time in the
|
Список | 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 по дате отправления: