Nico Grubert wrote at 2008-10-2 10:13 +0200:
These entries should not be the one that cause your problems (they are not computationally expensive). Do you see other entries as well?
Thank you very much for your answer, Dieter. There are 2 entries from in the DeadlockDebugger's output that may block all other threads.
If your tracebacks are reliable, then neither of these entries should cause "hanging" (apart from this: CPU usage of about 100 percent does not indicate hanging but some other problem). Tracebacks do not need to be reliable. They can be unreliable when the the "*.pyc/*.pyo" files do not correspond to the source. Therefore, an initial step may be to delete all "*.pyc/*.pyo" files and try again. There is one case when "hanging" could apparently happen in a "return": the operation before takes a long time and does not release the GIL. Then, the deadlock debugger will get active only when the operation finished -- and then sees an apparently harmless operation (such as a "return"). We have had severe garbage collection problems (GC, too, holds the GIL for a long time). To detect such problems, we have added a GIL monitor to our system. This is an additional thread running in the system which schedules itself at regular times and measures the difference between the expected scheduling time and the actual activation time. If the difference is too large, this is logged. If your system gets slow but still occasionally responds, you can use "ZopeProfiler" to find out, where the time is spend. Ensure to use "real time" as the timer (not cpu time). -- Dieter