On Fri, Mar 11, 2011 at 04:13:52PM +0100, hubert depesz lubaczewski wrote: > On Fri, Mar 11, 2011 at 03:03:55AM -0500, Noah Misch wrote: > > On Wed, Mar 09, 2011 at 09:38:07PM +0100, hubert depesz lubaczewski wrote: > > > So. every now and then (couple of times per day at most). I see hundreds > > > (800-900) of connections in "PARSE" state. > > > > > > I did notice one thing. > > > > > > we do log output of ps axo user,pid,ppid,pgrp,%cpu,%mem,rss,lstart,nice,nlwp,sgi_p,cputime,tty,wchan:25,args > > > every 15 seconds or so. > > > > > > And based on its output, I was able to get stats of "wchan" of all PARSE > > > pg processes when the problem was logged. > > > Results: > > > > > > 805 x semtimedop > > > 10 x stext > > > > > > Any ideas on what could be wrong? Machine was definitely not loaded most > > > of the times it happened. > > > > > > The problem usually goes away in ~ 10-15 seconds. > > > > Would you have your monitoring process detect this condition and capture stack > > traces, preferably from a gdb with access to debug information, of several of > > these processes? That will probably make the specific contention point clear. > > unfortunately debug was not enabled on this server, and changing > binaries would be rather complicated as it's production environment. Understood. Not a critical problem, most likely. > i'm not a c programmer, can you tell me how to get stack trace (assuming > it makes any sense without debug enabled) without damaging the process > in any way? gdb -ex=bt /path/to/bin/postgres $pid </dev/null I've used this on production systems to debug issues like this one, and I've never observed damage. The exact effect of debugger attach/detach may be OS/kernel-dependent, so it's hard to make categorical guarantees of safety. nm -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
