Hi, I have some questions about the Zope database cache. You can change the settings for this cache on the "Cache Parameters"-tab in the database management screen (/Control_Panel/Database). 1. The default target size is 400 objects. But the total number of objects in the combined caches is much larger. How does the target size influence the total number of objects in the cache? How should this setting be used? 2. "Total number of objects in all caches". I don't use any RamCacheManager. Does this mean that there is more than one database cache? Bert Vanderbauwhede... --- "Postmodernism is like a three year old throwing his blocks around the room because he got frustrated with his failed attempts to stack them higher."
I have some questions about the Zope database cache. You can change the settings for this cache on the "Cache Parameters"-tab in the database management screen (/Control_Panel/Database).
1. The default target size is 400 objects. But the total number of objects in the combined caches is much larger. How does the target size influence the total number of objects in the cache? How should this setting be used?
2. "Total number of objects in all caches". I don't use any RamCacheManager. Does this mean that there is more than one database cache?
These questions are interrelated - there is a db cache for each ZODB connection (should be 4 by default "out of the box" for Zope). So the total for all caches is just the number of object in each connection cache. This means that in theory, with a target size of 400, the system will try hard to make sure that no more than 1600 (persistent) objects are sitting around in memory (400 x 4 ZODB connections). This gives you some way of controlling memory usage, though it is not very fine-grained. The cache favors commonly used objects, which depending on your application may be tiny objects or huge objects. Cache tuning is still an art, not a science :) You need to look at your application behavior and the kinds of objects in memory (you can use the debug screen in the Control Panel to do that) and do some experimentation to find optimum settings. A well-tuned cache will strike a balance between keeping the objects that are used most often in the cache and desired memory footprint. Assuming your application doesn't do things that cause large memory spikes, this can give you a relatively predictable plateau for the amount of memory the process will consume. Hope this helps! Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
On Fri, 25 Oct 2002, Brian Lloyd wrote:
So the total for all caches is just the number of object in each connection cache. This means that in theory, with a target size of 400, the system will try hard to make sure that no more than 1600 (persistent) objects are sitting around in memory (400 x 4 ZODB connections).
OK, that explains it. I think that the 'in theory' part is important: I still got a lot more objects cached than 400 * 80 (my current #threads).
Hope this helps!
Yup. Thanks! Bert Vanderbauwhede... --- "Postmodernism is like a three year old throwing his blocks around the room because he got frustrated with his failed attempts to stack them higher."
So the total for all caches is just the number of object in each connection cache. This means that in theory, with a target size of 400, the system will try hard to make sure that no more than 1600 (persistent) objects are sitting around in memory (400 x 4 ZODB connections).
OK, that explains it. I think that the 'in theory' part is important: I still got a lot more objects cached than 400 * 80 (my current #threads).
On Zope 2.6, the reality is much closer to the theory (thanks to Toby Dickenson for his excellent cache overhaul). Older versions had issues in the cache implementation that made them far less effective than the 2.6 cache :) Brian Lloyd brian@zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com
On Friday 25 October 2002 3:53 pm, Bert Vanderbauwhede wrote:
On Fri, 25 Oct 2002, Brian Lloyd wrote:
So the total for all caches is just the number of object in each connection cache. This means that in theory, with a target size of 400, the system will try hard to make sure that no more than 1600 (persistent) objects are sitting around in memory (400 x 4 ZODB connections).
OK, that explains it. I think that the 'in theory' part is important: I still got a lot more objects cached than 400 * 80 (my current #threads).
Youve got 80 threads? thats crazy, unless: * you are running on a 40 cpu smp system * you have need to perform some off-box request (oracle query, perhaps) onto something with nearly that many cpus. If you come from an apache background and your intuition tells you that you need that many threads, then your intuition is wrong.
participants (3)
-
Bert Vanderbauwhede -
Brian Lloyd -
Toby Dickenson