[Zope] Zope hangs

[Dieter Maurer]

Nico Grubert wrote at 2008-10-9 10:17 +0200:
> ...
>> 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).
>
>Hi Dieter
>
>thank you very much for the information.
>
>This morning the server did not respond and all 8 threads in the 
>DeadlockDebugger's output look the same:
>
>Thread 1098918208
> ...
>   File "/zope/intranet/Products/LDAPUserFolder/LDAPUserFolder.py", line 
>1846, in _misc_cache
>     return getResource('%s-misc_cache' % self._hash, SharedObject, ())
>   File "/zope/intranet/Products/LDAPUserFolder/SharedResource.py", line 
>50, in getResource
>     _ResourceLock.release()

Your tracebacks really look strange: they almost all seem
to come from the release of looks.

Now, releasing a lock is a very fast operation.
An independent observer should rarely see the system in such
a state. That you see it there so often indicates that your
observer ("DeadlockDebugger") is not independent (we already knew that)
but in addition gets seriously confused -- thus, that we cannot trust
its observations when analysing the problem at hand.


You need to use a different observer.

As already written: if your Zope does not hang completely, "ZopeProfiler"
may be such an observer. It, too, is not independent, but different
things confuse it. Thus, we some luck, it may reveal the cause of
the current problems.

If your Zope hangs completely, then things get a bit more difficult.
You must attach the Zope process with a C level debugger. This
observer will not get confused by the Python GIL and is able
to observe threads that hold the GIL during long periods of time.
Unfortunately, quite a bit of preconditions must be met and
the analysis requires lots of knowledge about Python internas.
Therefore, I hope that you do not need an observer of this kind.



-- 
Dieter