[Chris McDonough]
The symptom you're describing has happened to me in the past. Zope stops serving requests and my CPU is not pegged (it's not hitting the CPU hard via an infinept loop I've made). I usually end up tracking it down to the fact that my instance is somehow leaking database connections.
[Chris Withers]
I thought Jim solved this for 2.8 by not having a hard limit on the connection pool?
This was implemented for ZODB 3.4. See: http://www.zope.org/Wikis/ZODB/SimplifyConnectionManagement and ZODB NEWS.
(iirc, you now get errors in the log when you go over the pool limit)
Messages at warning or critical level, depening on how much you've gone over.
This was 'cos you used to get the crappy situation running unit tests when lots of test fail that things hang and you get no feedback apart from 7 E's because the connection pool is exhausted.
Not really (see the Wiki page referenced above).
That said, I don't know for sure that Jim _did_ end up implementing this, I might just be imagine it.
It was released in ZODB 3.4a1: """ What's new in ZODB3 3.4a1? ========================== Release date: 01-Apr-2005 ... DB -- - There is no longer a hard limit on the number of connections that ``DB.open()`` will create. In other words, ``DB.open()`` never blocks anymore waiting for an earlier connection to close, and ``DB.open()`` always returns a connection now (while it wasn't documented, it was possible for ``DB.open()`` to return ``None`` before). ``pool_size`` continues to default to 7, but its meaning has changed: if more than ``pool_size`` connections are obtained from ``DB.open()`` and not closed, a warning is logged; if more than twice ``pool_size``, a critical problem is logged. ``pool_size`` should be set to the maximum number of connections from the ``DB`` instance you expect to have open simultaneously. In addition, if a connection obtained from ``DB.open()`` becomes unreachable without having been explicitly closed, when Python's garbage collection reclaims that connection it no longer counts against the ``pool_size`` thresholds for logging messages. The following optional arguments to ``DB.open()`` are deprecated: ``transaction``, ``waitflag``, ``force`` and ``temporary``. If one is specified, its value is ignored, and ``DeprecationWarning`` is raised. In ZODB 3.6, these optional arguments will be removed. """ And for ZODB 3.6, they were removed.