So.... as I am scalability testing, I see that my magmaSession cachedObjectCount is now 90000, i.e the whole database is in memory, and still growing. Isn't smalltalk great I can rewrite the code while the test is running.
So I figure if I can hunt down who is holding references to the datamodel and get them to let go, the cached object count and my memory usage will fall.
I track down one instance of something permanently referencing the root and re-code that. I also notice that due to the design of my Scalability testing framework it is holding at least one reference to the model in an instance var, even when it is paused and not doing anything. So I recoded it while it is running. Still 90000 object count. Where can it be?
How does one track down the offending item?
Keith
___________________________________________________________ All New Yahoo! Mail Tired of Vi@gr@! come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.html
Keith Hodges wrote:
How does one track down the offending item?
I haven't figured out how things are being held, but I find that the following code usually cleans up my image. Define these two methods, then run the doIt:
WASession>>resetInstVars continuations := nil. "application := nil." escapeContinuation := nil. monitor := nil. state := WAStateRegistry new. currentRequest := nil. scripts := nil. jumpTo := nil.
WARegistry>>clearHandlersUnsafe handlersByKey := Dictionary new. keysByHandler := Dictionary new.
WASession allSubInstances do: [:e | e resetInstVars]. WARegistry allSubInstances do: [:ea | ea clearHandlersUnsafe].
If you have custom a session class, then you may have to define a method to nil out the instaance variables, then call something like:
MySession allInstances do: [:e | e clearInstVars].
Hope that helps.
I presume you did a Smalltalk garbageCollect and a "mySession finalizeOids".. If that doesn't work then they are referenced somewhere. I've found things I didn't want around anymore referenced from block-temps before, a real pain.. These things can be hard to track down, even with the various pointer chhasers browsers but I have trouble with them (i.e., they sometimes show only the browser itself referencing)..
This is a bulk load right? What I've found is, after each commit, if you stub out the Pages you loaded, Squeak will garbage collect much better. It should significantly cut down on your cached objects (and improve performance).
--- Keith Hodges keith_hodges@yahoo.co.uk wrote:
So.... as I am scalability testing, I see that my magmaSession cachedObjectCount is now 90000, i.e the whole database is in memory, and still growing. Isn't smalltalk great I can rewrite the code while the test is running.
So I figure if I can hunt down who is holding references to the datamodel and get them to let go, the cached object count and my memory usage will fall.
I track down one instance of something permanently referencing the root and re-code that. I also notice that due to the design of my Scalability testing framework it is holding at least one reference to the model in an instance var, even when it is paused and not doing anything. So I recoded it while it is running. Still 90000 object count. Where can it be?
How does one track down the offending item?
Keith
___________________________________________________________ All New Yahoo! Mail Tired of Vi@gr@! come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.html _______________________________________________ Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
magma@lists.squeakfoundation.org