From: | "Jeffrey W(dot) Baker" <jwbaker(at)acm(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: postgres processes spending most of their time in the |
Date: | 2001-12-28 22:12:44 |
Message-ID: | Pine.LNX.4.33.0112281408300.23655-100000@windmill.gghcwest.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, 28 Dec 2001, Tom Lane wrote:
> [ 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.
Thanks for all your attention so far.
> 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?
I can provide as much dumping, logging, and tracing as you want, with the
single constraint of upstream network bandwith. I don't think files
larger than 100MB will be practical. I don't know what logging will be
useful, so someone will have to tell me what to do.
I don't think I can let anybody have access to this particular machine but
if I can reduce things to a simple testcase on another machine, I'll grant
access to that.
> 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.
strace unfortunately doesn't deref the sembuf structure in semop.
-jwb
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2001-12-28 22:26:15 | Re: postgres processes spending most of their time in the kernel |
Previous Message | Tom Lane | 2001-12-28 22:02:15 | Re: postgres processes spending most of their time in the kernel |