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).

Zope maillist  -
**   No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to