2007/10/9, Maciej Wisniowski <maciej.wisniowski@coig.katowice.pl>:

...

I set the number of threads: zserver-threads 25 I set: pool-size 27 on <zodb_db main> I think you should rather use ZEO than raise number of threads to such a big value. Also there are some rules about pool-size. I don't remember exactly but seems to me that it is too small, but in general I suppose it has nothing to do with your problem...

Situation you're seeing may appear if there is something that blocks all your threads, like all threads are waiting for RDBMS response...

...

How can i run some kind of debug on zope (debug-mode on dont log anything more) to check this next time happen? Use DeadlockDebugger and if this doesn't help try: http://www.zopelabs.com/cookbook/1073504990

-- Maciej Wisniowski

When i google it i find a post somewhere saying about increase the number of threads and the number of the pool, but nothing about this limitation! :( I will test DeadlockDebugger, but the main problem is only happen in the morning (around 8:00am-10:00am. 2007/10/9, Peter Bengtsson <peter@fry-it.com>:

Are you using any SQL connections or anything like that inside the Zope?

Not SQL, but LDAP yes. 2007/10/9, Dieter Maurer <dieter@handshake.de>:

You can try to analyse problems like this with the "DeadlockDebugger".

If the "DeadlockDebugger", too, does no longer respond, you need a C level debugger to attach to your Zope.

This requires a Python build with debugging symbols (this is the default when you yourself have built Python) and some internal knowledge (come back should you need it). -- Dieter

Thanks, if deadlockdebugger dont solve i will try gdb! 2007/10/9, Brian Sullivan <briansullivan@gmail.com>:

DeadlockDebugger certainly helped me in a similar situation.

I went through similar blind flailing machinations - modifying threads and pool sizes (in the end I found not a Zope or Plone coding problem but some of my Javascript code was inadvertently occasionally causing a tight looped remote access of a generated page --effectively a self inflicted DOS attack!)

Ok, it wasnt me who code the custom product of the site, i will try what was mentioned here and tomorrow i reply on the list. ty all! ^^

2007/10/9, Maciej Wisniowski <maciej.wisniowski@coig.katowice.pl>:

What kind of limitation? Instead of raising number of threads on one zope instance you should just use few Zope instances with smaller number of threads. AFAIK it's more effective.

I was talking about the limitation u say here: "Also there are some rules about pool-size. I don't remember exactly but seems to me that it is too small, but in general I suppose it has nothing to do with your problem..." I will search more about use of ZEO. Thanks.

So install deadlockdebugger and look at it's output between 8:00-10:00. It may be safely used on production instances.

Also check if some external resources like LDAP are not restarted/backed up or sth. like that at this time, or before (eg. there is a backup at night that causes 'something' wrong for connections from your zope and your users start working since 8:00 - thats when you see 'hangup').

I think is something on LDAP, Deadlockdebugger is running already and tomorrow i will have the answer. Thank u all...