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. Peter 2008/7/3 Garry Saddington <garry@schoolteachers.co.uk>:
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 Garry _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
-- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com