Heimo Laukkanen wrote at 2004-5-25 22:46 +0300:
...
What does "Control_Panel --> Debug information" tells you about the use of your connections (at the bottom of the page)?
At the moment it said that only one opened connection and others were none. I have no terminal access to the machines at the moment to check how threads are behing at the moment.
That looks strange... Maybe, the only running thread does not release the GIL?
And then backtrace with gdb from those quiet threads
My most essential tools when analysing Python code in "gdb" are the following two GDB command definitions. def ps x/s ({PyStringObject}$arg0)->ob_sval end def pfr ps f->f_code->co_filename ps f->f_code->co_name p f->f_lineno end "ps" allows you to look at a Python String variable and "pfr" can be called in "eval_frame" frames. It tells you what code this frame is executing -- identified by module and function. You cannot trust the "lineno" in Python 2.3 (it is the start of the function not where you actually are).
~# gdb program 14552 backtrace ... #7 0x080a22f6 in eval_frame (f=0x9b5ea24) at Python/ceval.c:2116
use "fr 7" to select this frame and then "pfr" to see where this is.
... Another thread ( 14548 )
#0 0x401153c4 in read () from /lib/libc.so.6 #1 0x40029ae0 in __DTOR_END__ () from /lib/libpthread.so.0 #2 0x412474f0 in nttrd () from /opt/portaali/comp/oracle/lib/libclntsh.so.9.0 #3 0x410fdcf8 in nsprecv () from
Obviously, this is a call to Oracle. Maybe, the GIL is not released?
... #14 0x40e13631 in Cursor_execute (self=0x4216fcd0, args=0x4017002c) at src/dco2.c:3740
The GIL should have been released in the function above. Check it for "Py_BEGIN_ALLOW_THREADS", "Py_END_ALLOW_THREADS" around line 3740.
.... PID: 14547
#0 0x401153c4 in read () from /lib/libc.so.6 #1 0x40029ae0 in __DTOR_END__ () from /lib/libpthread.so.0 #2 0x412474f0 in nttrd () from /opt/portaali/comp/oracle/lib/libclntsh.so.9.0
This, too is waiting for Oracle...
PID: 14545
#0 0x401153c4 in read () from /lib/libc.so.6 #1 0x40029ae0 in __DTOR_END__ () from /lib/libpthread.so.0 #2 0x412474f0 in nttrd () from /opt/portaali/comp/oracle/lib/libclntsh.so.9.0 #3 0x410fdcf8 in nsprecv () from This, too...
PID: 14531
#0 0x4011c7ee in select () from /lib/libc.so.6 #1 0x40568cb4 in __DTOR_END__ () from /opt/portaali/ContentManagement-1.0/python-2.3.3/lib/python2.3/lib-dynload/select.so #2 0x080e0e3f in PyCFunction_Call (func=0x4049636c, arg=0x426476e4, kw=0x0) at Objects/methodobject.c:73 #3 0x080a3beb in call_function (pp_stack=0xbffff11c, oparg=4) at Python/ceval.c:3439 #4 0x080a22f6 in eval_frame (f=0x9033f64) at Python/ceval.c:2116
Check where you are here (--> "pfr"). It may be the medusa/asyncore main loop. You have several threads waiting for responses from Oracle. Are you sure that "Control_Panel --> Debug information" tells you only about a single ZODB connection? -- Dieter