On Fri, 7 Apr 2000, John Morton wrote:

...

Most of that memory is actually shared between the threads, so the size of one thread is closer to your real memory usage.

Is this a factual statement or is it a conjecture? I used the Unix command "top" to see the memory usage, and each thread was occupying a physical memory size of 23 MB (before I restarted and packed Zope.) After I restarted and packed Zope, it's started to take about 7MB and slowly increased now taking up 12 MB, each thread. The previous boot up of Zope has been running for about a week, so I still can't guarantee it won't climb up again to 23 MB.

...

A lot of that memory usage will be cached objects, cached Sybase queries, and the Gadfly database, which is kept in memory.

Oops, just as I am typing this message, after accessing another table in Sybase, the memory usage went up to 14 MB. So I think the Sybase queries are definitely the ones to blame. My SybaseDAv2 adapter has been REALLY SLOW, too, about 0.3 sec per query. So I think there is either some inefficiency or memory leak in SybaseDAv2. Arrghh... why would SybaseDAv2 take up the task of caching queries result? This does not make a lot of sense.... The database server should be the one caching results, not the adapter...

...

Try flushing Zope's cache and packing it after a restart to see what the 'base' memory usage should be.

Thanks. It was 7 MB, about the size of Data.fs.

...

Everything else will be cache (unless there really is some hitherto unknown memory leak!).

Probably memory leak in Sybase adapter... I seem to remember someone mentioned this before (?), not sure, though. I will dig in some more.

There must be. If one is lucky and the Zope process doesn't crash for a long timeone will find that the process takes way more memory than (thread number)xData.fs size. I have seen it with many Zope installations even with very simple ones.

thanks, Hung Jung ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com