performance tuning of ZODB
I've used the cache_size paramter to the constructor of the DB to good effect. Are there any further gotchas for ensuring that the ZODB stays in memory as much as possible?
On Thursday 22 April 2004 10:42, Syver Enstad wrote:
I've used the cache_size paramter to the constructor of the DB to good effect. Are there any further gotchas for ensuring that the ZODB stays in memory as much as possible?
Memory usage scales proportional to the number of threads. Reducing the number of worker threads lets you increase the per-thread cache size. -- Toby Dickenson
Toby Dickenson <tdickenson@geminidataloggers.com> writes:
On Thursday 22 April 2004 10:42, Syver Enstad wrote:
I've used the cache_size paramter to the constructor of the DB to good effect. Are there any further gotchas for ensuring that the ZODB stays in memory as much as possible?
Memory usage scales proportional to the number of threads. Reducing the number of worker threads lets you increase the per-thread cache size.
I don't use connection per thread semantics but I think I understand what you mean. I should pass a lower number than the default to the pool_size keyword argument for the DB constructor? What about the other arguments to the DB constructor? cache_deactivate_after sounds interesting. Since I am running ZODB in a web server I don't want the data to timeout and disappear from memory since every object I have should be loaded at all times.
On Thursday 22 April 2004 11:43, Syver Enstad wrote:
cache_deactivate_after sounds interesting. Since I am running ZODB in a web server I don't want the data to timeout and disappear from memory since every object I have should be loaded at all times.
Thats why ZODB ignores that parameter now ;-) -- Toby Dickenson
Toby Dickenson <tdickenson@geminidataloggers.com> writes:
On Thursday 22 April 2004 11:43, Syver Enstad wrote:
cache_deactivate_after sounds interesting. Since I am running ZODB in a web server I don't want the data to timeout and disappear from memory since every object I have should be loaded at all times.
Thats why ZODB ignores that parameter now ;-)
Good :-) I have a strange case here with ReadConflictErrors. I don't know if this is covered already but anyway. I am using ZODB 3.2 so this might be fixed in 3.3 for all I know. Just replace the twisted stuff with the standard lib unittest module to have it work on a computer without twisted installed.
Hi Syver, Please add this issue to the Collector, including the test (prefereably without the twisted bits) On Thu, 2004-04-22 at 12:57, Syver Enstad wrote:
[...]
I have a strange case here with ReadConflictErrors. I don't know if this is covered already but anyway. I am using ZODB 3.2 so this might be fixed in 3.3 for all I know.
Just replace the twisted stuff with the standard lib unittest module to have it work on a computer without twisted installed.
-- Leonardo Rochael Almeida <leo@hiper.com.br>
[Leonardo Rochael Almeida]
Please add this issue to the Collector, including the test (prefereably without the twisted bits)
[Syver Enstad]
Eh, what is the Collector?
The zope.org Collectors are here: http://www.zope.org/Collectors/ and you want the Zope Collector: http://zope.org/Collectors/Zope/ It's where bug (or "issue") reports are stored and managed. Maling lists don't work for this purpose.
participants (4)
-
Leonardo Rochael Almeida -
Syver Enstad -
Tim Peters -
Toby Dickenson