From: | Jim Vanns <james(dot)vanns(at)framestore(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jim Vanns <james(dot)vanns(at)framestore(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Odd blocking (or massively latent) issue - even with EXPLAIN |
Date: | 2012-07-23 15:49:25 |
Message-ID: | 1343058565.12579.126.camel@sys367.ldn.framestore.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Mon, 2012-07-23 at 11:09 -0400, Tom Lane wrote:
> Jim Vanns <james(dot)vanns(at)framestore(dot)com> writes:
> > We're seeing SELECT statements and even EXPLAIN (no ANAYLZE)
> > statements hang indefinitely until *something* (we don't know what)
> > releases some kind of resource or no longer becomes a massive bottle
> > neck. These are the symptoms.
>
> Does anything show up as blocked in the pg_locks view?
Nope.
> Could you attach to the stuck process with gdb and get a stack trace?
Haven't been quite brave enough to do that yet - this is a production
server. I did manage to strace a process though - it (the server side
process of a psql EXPLAIN) appeared to spin on an awful lot of semop()
calls with the occasional read(). Of course, in the context of a shared
memory system such as postgres I'd expect to see quite a lot of semop()
calls but I've no idea how much is normal and how much is excessive.
Jim
> regards, tom lane
>
--
Jim Vanns
Systems Programmer
Framestore
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2012-07-23 19:07:10 | Re: postgres clustering interactions with pg_dump |
Previous Message | Tom Lane | 2012-07-23 15:09:16 | Re: Odd blocking (or massively latent) issue - even with EXPLAIN |