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
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
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
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.
Here is the
import time
T0 = time.time()
conn.simple_bind_s(user_dn, user_pwd)
T1 = time.time()
open('/tmp/timings.log','a').write('%s\n' % (T1-T0))
Thanks, Peter.
I tried that and the max value for T1-T0 I got was: 0.162416934967
Regards
Nico
Hi there
in the last days my Zope server seems to hang and the CPU is almost
every time at 100 %.
I installed DeadlockDebugger and see a lot of these entries:
-
File
Yes, and you can use the Control_Panel/DebugInfo as well and scroll
down to the Connections table. Out of the 8 threads most of them
should be vacant (ie. None) and if there are some requests logged
there they should in the range of 1 sec.
If any of them are longer than 1 sec they are either
Yes, and you can use the Control_Panel/DebugInfo as well and scroll
down to the Connections table. Out of the 8 threads most of them
should be vacant (ie. None) and if there are some requests logged
there they should in the range of 1 sec.
If any of them are longer than 1 sec they are either
2008/9/30 Nico Grubert [EMAIL PROTECTED]:
Yes, and you can use the Control_Panel/DebugInfo as well and scroll
down to the Connections table. Out of the 8 threads most of them
should be vacant (ie. None) and if there are some requests logged
there they should in the range of 1 sec.
If any of
Nico Grubert wrote at 2008-9-30 11:49 +0200:
in the last days my Zope server seems to hang and the CPU is almost
every time at 100 %.
When your CPU is almost at 100 % over an extended period,
then you do not have a typical hanging problem but rather
something like a busy loop.
I installed
Hmmm...unfortunately, that's not the cause of the problem (I'm
responding since I'm on the East coast, Jean is on the West, and he's
asleep right now):
[EMAIL PROTECTED]: ~$ python
Python 2.4.3 (#2, Jul 2 2006, 16:14:54)
[GCC 3.4.2 [FreeBSD] 20040728] on freebsd5
Type help, copyright, credits
My understanding is that get/setrecursionlimit is for the python
internal limit and is not an indicator of the THREAD_STACK_SIZE value,
but in any case, yes, we have compiled with that option and I don't
think that these would be the symptoms I would see for a stack size
issue anyway, but thanks
All,
As a coincidence, that hang of Zope I mentioned in a message I posted
yesterday has happened again today (second time), after a planned
reboot. So here is a completely different issue from the memory one
we've been discussing today.
There was other weirdness (for whatever reason _mysql
http://plone.org/documentation/faq/plone-on-bsd-python-stack
Stefan
On 26. Feb 2007, at 06:06, Jean Lagarde wrote:
All,
As a coincidence, that hang of Zope I mentioned in a message I posted
yesterday has happened again today (second time), after a planned
reboot. So here is a completely
Hi Nico,
I've also struggled with Easysoft's OOB (Odbc-Odbc Bridge) and with dire
results. The main problem we had wasn't seg faults but that it got hung
up and stopped responding probably due to abandonned closed connection
sockets.
On a completely different customer I managed to get a Zope
Nico Grubert wrote at 2007-2-9 08:56 +0100:
...
After I started Zope and make a few SQL queries, the Zope server shuts
down with a Segmentation fault.
At the same time there is a log entry on my linux machine in
/var/log/messages that reads:
Jan 23 10:43:09 smut kernel: python[6231]: segfault at
I am running Zope 2.9.6. on a 64-Bit Suse Linux 10.1 machine (9 Gbyte of
RAM) with Python 2.4.3. installed.
From time to time, Zope hangs and I cannot access it anymore. I tried
to use the Zope DeadlockDebugger but if my Zope hangs I cannot call
the URL
Nico Grubert wrote at 2007-1-15 13:22 +0100:
I am running Zope 2.9.6. on a 64-Bit Suse Linux 10.1 machine (9 Gbyte of
RAM) with Python 2.4.3. installed.
From time to time, Zope hangs and I cannot access it anymore. I tried
to use the Zope DeadlockDebugger but if my Zope hangs I cannot call
the
Dear list members,
I am running Zope 2.9.6. on a 64-Bit Suse Linux 10.1 machine (9 Gbyte of
RAM) with Python 2.4.3. installed.
From time to time, Zope hangs and I cannot access it anymore. I tried
to use the Zope DeadlockDebugger but if my Zope hangs I cannot call
the URL
On Mon, Jan 15, 2007 at 01:22:39PM +0100, Nico Grubert wrote:
Dear list members,
I am running Zope 2.9.6. on a 64-Bit Suse Linux 10.1 machine (9 Gbyte of
RAM) with Python 2.4.3. installed.
From time to time, Zope hangs and I cannot access it anymore. I tried
to use the Zope
Besides DeadlockDebugger, is there a way to see just how many threads
Zope is currently using ?
What do you mean by 'currently using'? Zope instance
always uses the number of threads you've
specified in zope.conf.
You may try 'ps -aux|grep zope' if you're on linux box.
If you want to see
When zope hangs you may take a look at your console or
file to see what is the state of threads.
Ergh.. I should have written that you'll see whether threads
are waiting for database... If any thread does something
different it won't be shown here.
--
Maciej Wisniowski
On 9/7/06, Maciej Wisniowski [EMAIL PROTECTED] wrote:
When zope hangs you may take a look at your console or
file to see what is the state of threads.
Ergh.. I should have written that you'll see whether threads
are waiting for database... If any thread does something
different it won't be
Sorry for the typo error.
The subject should read "hangs", not "hands"
.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Sinang, DannySent:
Wednesday, September 06, 2006 10:56 PMTo:
zope@zope.orgSubject: [Zope] Zope hands when database takes too long
to respond
Hello,
Whenever the MySQL server experiences heavy load, Zope seems to hang,
such that we can't even access the ZMI.
Is this a bug in version 2.7.6 or ZMySQLDA ?
Seems that all your Zope threads are busy (they're waiting
for database response). There is no more threads to serve
next requests so
Seems that all your Zope threads are busy (they're waiting for
database response). There is no more threads to serve next requests so
they're waiting (you may say that zope hangs in this situation, but in
fact all it's threads are waiting for DB).
You may install DeadlockDebugger product and
Yuan HOng wrote at 2005-10-27 18:18 +0800:
...
I have a site running with Zope 2.7.6 under Linux. The site access a
PostgreSQL database through ZSQL and psycopg 1.1.18. Only read access
is used, nothing is written to the database.
The one thing that annoys me very much is, with time passing,
Hi, list,
I have a site running with Zope 2.7.6 under Linux. The site access a
PostgreSQL database through ZSQL and psycopg 1.1.18. Only read access
is used, nothing is written to the database.
The one thing that annoys me very much is, with time passing, Zope
will eventually hang and has to be
28 matches
Mail list logo
