On 12/10/2010 17:56, Jim Fulton wrote:
> Currently the only configuration "docs" are in the .xml Alan provided a link 
> to.
> The best size will depend on the app.

Is there a downside to "too big", provided there's plenty of disk space 
free on the app servers?

> There are some docs in
> http://svn.zope.org/ZODB/trunk/doc/, although I don't know if they're 
> accurate.

...yeah, those look a lot like the original docs that Guido(?) wrote.

> In ZODB 3.10, the cache tracing analysis tools actually work and produce
> meaningful numbers if you start tracing with an empty cache.

Okay, does that mean the stuff that's documented should be ignored for 
ZODB 3.9?

I went for the following in the end:

       cache-size 200Mb
       client     app
       wait       on
     mount-point /
     cache-size       50000
     cache-size-bytes 500Mb

Any obvious issues with that?

One problem I did hit, though, was if I restarted an app server, I got:

line 210, in open
line 395, in __init__
     self._cache = self.ClientCacheClass(cache_path, size=cache_size)
"/var/buildout-eggs/ZODB3-3.9.6-py2.6-linux-i686.egg/ZEO/cache.py", line 
194, in __init__
     self._lock_file = zc.lockfile.LockFile(path + '.lock')
"/var/buildout-eggs/zc.lockfile-1.0.0-py2.6.egg/zc/lockfile/__init__.py", line 
76, in __init__
"/var/buildout-eggs/zc.lockfile-1.0.0-py2.6.egg/zc/lockfile/__init__.py", line 
59, in _lock_file
     raise LockError("Couldn't lock %r" % file.name)
LockError: Couldn't lock '....zec.lock'

...and yet the app server came up fine. What does this error message imply?

The above did not, however, occur if I stopped and then started the app 

Race condition?


Simplistix - Content Management, Batch Processing & Python Consulting
            - http://www.simplistix.co.uk
For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to