Yes, couldn't agree more with kevin. DeadlockDebugger is crucial. It
won't change anything other than that you'll have information about
what really needs to change.
As an intermediate solution you can start to increase the number of
Zope threads from 4 to 6 or 8 and see if that kills the CPU of your
beefy server. Too many threads can hurt performance especially when
working with badly coded external connectors that selfishly hook
itself to the python GIL too much.
A lightweight alternative to DeadlockDebugger is the table at the
bottom of the Debug Information page in Control_Panel. If any of the
dates in the first column in that table shows times longer than a
second you have a problem with those requests.
2008/7/3 Garry Saddington <[EMAIL PROTECTED]>:
> Following a hard disk crash 2 weeks ago we have installed Zope onto a new
> server and all was fine until yesterday morning when Zope stopped responding
> and required a restart to get it working. It did the same at 3-30pm today.
> We are using Zope 2.9.0 on Centos 5.1 on a quad Zeon server with 4gb. Ram. At
> the moment the server is in quite heavy use with teachers trying to write
> reports for a deadline tomorrow. These are sent to a Postgres DB via psycopg.
> There is nothing in Z2.log or event.log to point me to the problem. I am
> therefore asking for advice on the sorts of things that can cause Zope to
> stop responding and whether there is anything we can do to mitigate against
> such an event.
> Thanks and regards
> Zope maillist - Zope@zope.org
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://mail.zope.org/mailman/listinfo/zope-dev )
Zope maillist - Zope@zope.org
** No cross posts or HTML encoding! **
(Related lists -