Re: [ZODB-Dev] Slow Zeo load times after upgrade to ZODB 3.4
Erik A. Dahl wrote at 2005-10-21 15:43 -0400: The ZODB cache lives in RAM and is a Python object cache. It is a per connection cache. The ZEO client cache lives on disk and is a pickle cache (it caches the object states not the objects themselves). It is shared by all connections to a single storage (in one process). How do these two relate to each other? You see a cache hierarchy: application worldZODB cache ZEO Client Cache ZEO Server (Python objects)(Python objects) object statesobject states The ZEOClientStorage fetches an object's state from its cache. In case of a cache miss, it fetches it from the ZEO server. The ZEO Client Cache can save you the network interaction. Do I really need the disk cache? I do not know... The ZEO developpers were convinced it were essential. They spent considerable time to optimize and tune it... Do you really care? Do you need to live with 1 GB disks (wide spread a decade ago)? Can it be turned off? Sure, when you change the code. Otherwise, you can make it small but not turn it off. I don't have client set so that each process makes its own cache file. (When I set this I have problems if two processes us the same zope.conf file). Is there a doc somewhere explaining all of this?? ZConfig based software components (such as Zope and ZEO) provide valuable information in the configuration schema (usually found in files named schema.xml or component.xml; the Zope configuration schema is in .../Zope[2]/Startup/zopeschema.xml) A further valuable documentation source are the docstrings embedded in the source code. There are also documents around about the ZODB and ZEO (but I will not search them for you). -- Dieter ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Slow Zeo load times after upgrade to ZODB 3.4
Paul Winkler wrote at 2005-10-21 16:24 -0400: ... Why do you want to use the same zope.conf, and how can that possibly work anyway? You can't run two servers on the same port! He might use the same configuration file on different hosts. And I posted a ZConfig extension that allows to read the environment (thus using environment variables in the configuration file). With this extension, you can control some options with different environment variables. We use this heavily. (Of course, the same mechanism can provide different effective values for the client config option, as well). -- Dieter ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Slow Zeo load times after upgrade to ZODB 3.4
On 10/22/05, Dieter Maurer [EMAIL PROTECTED] wrote: Paul Winkler wrote at 2005-10-21 16:24 -0400: ... Why do you want to use the same zope.conf, and how can that possibly work anyway? You can't run two servers on the same port! He might use the same configuration file on different hosts. Sure, but then the config file wouldn't have problems with the persistent cache, so I assumed that was not what he meant. And I posted a ZConfig extension that allows to read the environment (thus using environment variables in the configuration file). With this extension, you can control some options with different environment variables. We use this heavily. That sounds useful. -PW -- http://www.slinkp.com ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
Re: [ZODB-Dev] Slow Zeo load times after upgrade to ZODB 3.4
Erik A. Dahl wrote at 2005-10-21 08:56 -0400: I just upgraded a client site from zope 2.6.2 to 2.8.1 (which I think has ZODB 3.4.1). After the upgrade I'm seeing very slow initial load times for objects from the zeo server (much slower than before). I understand that the objects need to be loaded from disk (and transfered to the client) but during the initial period (pre-cache) I see the CPU spike to 100%. This must mean it isn't a disk problem as much as a server to client transfer issue. We did not observe this behaviour... Here are some configuration parameters I have played with to try and improve things: zodb_db cache-size - is this a per thread number as before or is it for all threads? Nothing changed (other than that it is not defined in the configuration file and not in the ZMI). I have never seen it reach my setting. Before the cache would get to the target number quickly. I assume this is active objects (ie doesn't include ghosts?) Yes. zeoclient cache-size - how does this interact with the above setting? and how is it different (besides being in bytes). The ZODB cache lives in RAM and is a Python object cache. It is a per connection cache. The ZEO client cache lives on disk and is a pickle cache (it caches the object states not the objects themselves). It is shared by all connections to a single storage (in one process). ... My database has around 350k objects. I have zodb_db cache-size set to 200k That is quite courageous... Watch your RAM requirements closely! -- Dieter ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
RE: [ZODB-Dev] Slow Zeo load times after upgrade to ZODB 3.4
[Dieter Maurer] The ZODB cache lives in RAM and is a Python object cache. It is a per connection cache. The ZEO client cache lives on disk and is a pickle cache (it caches the object states not the objects themselves). It is shared by all connections to a single storage (in one process). [Erik A. Dahl] How do these two relate to each other? When an application using ZEO tries to load a persistent object: 1. It first looks in the ZODB cache. 2. If that's a miss (the object is not in the ZODB cache), it consults the ZEO cache. 3. If that's a miss too (the object isn't in the ZEO cache either), it asks the ZEO server for the object's state. So wrt the ZODB cache, the ZEO cache is a second-level cache. The ZODB cache has a least-recently used replacement policy, and the hope is that not-recently-used objects that have been booted from the ZODB cache can usually still be found in the ZEO cache, saving the usually much greater expense of fetching state from the ZEO server over the network. Do I really need the disk cache? If you want to use ZEO, yes. Can it be turned off? No, but you can change its size. If you're suffering from slow network performance, though, you probably don't want to make it smaller. I don't have client set so that each process makes its own cache file. That means it's a non-persistent cache file: it's thrown away when the ZEO client stops, and the ZEO client doesn't remember any objects across restarts. (When I set this Setting client makes it a persistent cache file: the ZEO client then remembers (as much as it can) object states across restarts. There are complicated tradeoffs here. Using a persistent cache is potentially much faster after initial startup, but _may_ make initial startup slower. This is because, when using a persistent cache, the ZEO client has to talk with the ZEO server when it starts up, to figure out which objects have changed state since the ZEO client last talked with the server. A number of strategies are used to speed that negotiation, but any or all may or may not be effective depending on details. Separately, when using a persistent cache the ZEO client has to scan the entire cache file on startup in order to build an in-memory map of which objects it knows about and where they live in the cache file. If, e.g., you have a slow disk and/or very large cache file, that can take appreciable time. By the way, setting invalidation-queue-size won't help you across a client restart unless the client is using a persistent cache file (the ZEO server invalidation queue is one of the strategies mentioned above that aims at speeding startup cache verification for persistent cache files). I have problems if two processes us the same zope.conf file). I believe that ;-) ... ah, I see Paul Winkler already explained good practice wrt this. Is there a doc somewhere explaining all of this?? Not really, at least not that I know of. It would need to be a really fat book to explain all of it. ___ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org http://mail.zope.org/mailman/listinfo/zodb-dev
