zope 2.8.5 becomes unresponsive.
Environment is RHEL 3, Zope v2.8.5 (Python 2.3.5). Every couple of days the zope instance will become unresponsive and require a restart. ZMI is inaccessible at these times so I have to do run "service my_zope_service restart" in the usual redhat way. There is nothing in the logs, and if I do "service y_zope_service status" I am told "program running; pid=22671" This is a service under very light load. I viewed the chanelog for v2.8.6 and didn't see any changes that address this, and for various reasons I do not want to move into the v2.9.x builds. Any guidance appreciated.
On Thu, Apr 20, 2006 at 05:58:29AM -0700, Erik Myllymaki wrote:
Environment is RHEL 3, Zope v2.8.5 (Python 2.3.5).
Every couple of days the zope instance will become unresponsive and require a restart. ZMI is inaccessible at these times so I have to do run "service my_zope_service restart" in the usual redhat way.
There is nothing in the logs, and if I do "service y_zope_service status" I am told "program running; pid=22671"
This is a service under very light load.
I viewed the chanelog for v2.8.6 and didn't see any changes that address this, and for various reasons I do not want to move into the v2.9.x builds.
Any guidance appreciated.
google for two things: zope deadlock debugger "debug spinning zope" -- Paul Winkler http://www.slinkp.com
-----Message d'origine----- De : zope-bounces@zope.org [mailto:zope-bounces@zope.org] De la part de Paul Winkler Envoyé : jeudi 20 avril 2006 15:30 À : zope@zope.org Objet : Re: [Zope] zope 2.8.5 becomes unresponsive.
On Thu, Apr 20, 2006 at 05:58:29AM -0700, Erik Myllymaki wrote:
Environment is RHEL 3, Zope v2.8.5 (Python 2.3.5).
Every couple of days the zope instance will become unresponsive and require a restart. ZMI is inaccessible at these times so I have to do run "service my_zope_service restart" in the usual redhat way.
There is nothing in the logs, and if I do "service y_zope_service status" I am told "program running; pid=22671"
This is a service under very light load.
I viewed the chanelog for v2.8.6 and didn't see any changes that address this, and for various reasons I do not want to move into the v2.9.x builds.
Any guidance appreciated.
google for two things: zope deadlock debugger "debug spinning zope"
--
Hello, I've read documentation about deadlock and apparently the CPU usage should be high, isn't it ? Because in my case the CPU usage is falling to 0.0 (while the python process is still alive). Sebastien
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21 Apr 2006, at 07:52, Sébastien VINOT wrote:
I've read documentation about deadlock and apparently the CPU usage should be high, isn't it ? Because in my case the CPU usage is falling to 0.0 (while the python process is still alive).
No. Deadlocks cannot be identified by CPU usage. If Zope hangs, there is a deadlock. Use the diagnostic methods described in the documents you looked up. jens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFESJ2iRAx5nvEhZLIRAiQ7AKCdWKcS8d0nh80djOdVNkrtGFzsRACgssng JNnz286zi8qJMFI4CgQe0iI= =27JP -----END PGP SIGNATURE-----
I got a chance to try and debug with the the DeadlockDebugger, but it was unresponsive... Still nothing in the event log. Any other ideas? Jens Vagelpohl wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 21 Apr 2006, at 07:52, Sébastien VINOT wrote:
I've read documentation about deadlock and apparently the CPU usage should be high, isn't it ? Because in my case the CPU usage is falling to 0.0 (while the python process is still alive).
No. Deadlocks cannot be identified by CPU usage. If Zope hangs, there is a deadlock. Use the diagnostic methods described in the documents you looked up.
jens
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin)
iD8DBQFESJ2iRAx5nvEhZLIRAiQ7AKCdWKcS8d0nh80djOdVNkrtGFzsRACgssng JNnz286zi8qJMFI4CgQe0iI= =27JP -----END PGP SIGNATURE----- _______________________________________________ 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 )
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Erik Myllymaki wrote:
I got a chance to try and debug with the the DeadlockDebugger, but it was unresponsive...
Still nothing in the event log.
Any other ideas?
You might enable the 'trace_log' option, and then use the 'requestprofiler.py' script to show which requests are failing to complete. Configuring the log file: http://mail.zope.org/pipermail/zope/2005-April/158309.html To use the profiler: $ /path/to/python $ZOPE_HOME/utilities/requestprofiler.py --help Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFETO48+gerLs4ltQ4RAi2IAKC8vOHl/0ZLXYb82gipl3ehikrKYQCfYv8i 8kIvCFnUYLFsfwmYaiiB4Gg= =SNAL -----END PGP SIGNATURE-----
I have had zopes like that on different linux versions. Following identified reasons on the different installations: 1. LDUF timeout(s) where -1 After upgrading LDUF where you could set timeouts and linux/zope version the operation -1 timeout caused deadlock and no response from zope for 5-15 minutes, depending on the timeout in the system call. Setting the timeout >0 solved it on this instance. 2. LinguaPlone had a bug or something, Jodok found this and it's fixed on the trunk. 3. Suspect: CacheFu - Memcache broken On Fedora 3 zope 2.8.x, I hade CacheFu and no debug on so I didn't see that the Memcache product in CacheFu was broken due missing memcache module. After turning the zope into debug and removing the Memcache product it has worked perfect. Hope this helps. /Sasha
Am 29.04.2006, 21:36 Uhr tat Sasha Vincic <sasha.vincic@gmail.com> schraben:
I have had zopes like that on different linux versions. Following identified reasons on the different installations:
1. LDUF timeout(s) where -1 [...] 2. LinguaPlone had a bug or something, Jodok found this and it's fixed on the trunk. [...] 3. Suspect: CacheFu - Memcache broken [...]
Another thing I came across some times: 4. some method called while working on a request executed a HTTP GET for something else inside the same Zope instance (e.g. via urllib). Have some of these requests running simultanously and chances are pretty big that they'll hang around endlessly waiting for each other to finish and free up a Zope thread to answer their own sub-request. This will typically result in very little to almost no CPU usage. Good luck! Jo. -- internetmanufaktur jo----------------------------- Berlin, Germany |||||||||||||||meder------------------- fon: ++49-30-44 04 27 82 http://www.meder.de/ -------------------- fax: ++49-30-44 04 30 95 Kollwitzstr. 75 ------------------------ mob: ++49-170- 2 98 89 97 10435 Berlin ---------------http://www.meder.de/keys/jo-pubkey.txt
participants (7)
-
Erik Myllymaki -
Jens Vagelpohl -
Jo Meder -
Paul Winkler -
Sasha Vincic -
Sébastien VINOT -
Tres Seaver