[Glass] Lots of seaside objects not being GCed (need gemstone advise)

[Dale Henrichs via Glass]

On 07/06/2015 03:09 PM, Mariano Martinez Peck wrote:
>
>
> On Mon, Jul 6, 2015 at 6:47 PM, Dale Henrichs 
> <dale.henrichs at gemtalksystems.com 
> <mailto:dale.henrichs at gemtalksystems.com>> wrote:
>
>
>     On 07/06/2015 12:28 PM, Mariano Martinez Peck wrote:
>>
>>
>>     On Mon, Jul 6, 2015 at 2:33 PM, Dale Henrichs via Glass
>>     <glass at lists.gemtalksystems.com
>>     <mailto:glass at lists.gemtalksystems.com>> wrote:
>>
>>         Mariano,
>>
>>         I've read over your other messages and I guess you are still
>>         struggling to clean these guys up ... Rest of my comments in
>>         line.
>>
>>
>>     Hi Dale.
>>     Thanks, I answer inline.
>>
>>         Dael
>>
>>         On 07/03/2015 08:22 PM, Mariano Martinez Peck via Glass wrote:
>>>
>>>         Then...I check some #allInstances size and I get this:
>>>
>>>         DpWebSession allInstances size 32
>>>         WACallbackRegistry allInstances size 217
>>>         JQueryClass allInstances size 16519
>>>         WACache  allInstances size 35
>>>         WAApplication allInstances size 3
>>>         WARenderVisitor allInstances size 217
>>>         WARenderContext allInstances size 217
>>>         WAHtmlCanvas allInstances size 909
>>>         .....
>>>
>>         Right off the bat, my observation is that this doesn't seem
>>         like a  lot of uncollected objects, presumably you churn
>>         through a lot more sessions than this on a regular basis, so
>>         these objects appear to be the exception instead of the rule...
>>
>>
>>     Of course. All those numbers are in a system which didn't receive
>>     a single request in a whole day. And this is the results after
>>     all the cleanings I could do. So this is why I expect to have
>>     zero instances of those (meaning .. no zero, but much less in the
>>     real system that what I have now),.
>     Okay, you didn't have a single request today, so these objects
>     must be hanging around from a previous day. Did you have zero
>     instances the day before?
>
>     Without any other information, it is possible that these objects
>     got left behind because of a voting issue (i.e., reference left in
>     the head of a vm) ... did you cycle all of the gems before running
>     the mfc? What is your setting for
>     GEM_TEMPOBJ_POMGEN_PRUNE_ON_VOTE? If I'm not mistaken
>     GEM_TEMPOBJ_POMGEN_PRUNE_ON_VOTE does not guarantee that there
>     aren't other references in the gems head to objects ...
>
>     These instances did not appear out of thin air and there is a
>     logical reason for them to be still hanging around ... This a
>     complicated system with a number of moving parts and there is no
>     way to rule out bugs either ...
>
>     Without a detailed accounting of the "starting point" and the
>     gems, started and stopped between that point and now it is
>     impossible to guess we cannot guess what might have happened ...
>
>     I would suggest that at some point you record the oops of the
>     session objects so that we don't end up finding that every time we
>     look we are looking at a different set of sessions ...
>
>
>
> Good point. Thanks. I will remember it for next time: each time I am 
> dealing with this kind of stuff: cycle all seaside gems first!
> Thanks. BTW, my GEM_TEMPOBJ_POMGEN_PRUNE_ON_VOTE is 100% now to avoid 
> having to cycle gems.
> I will continue with the tests with cycling/killing the gems... 
> but.... continue reading below...
Do you also have the marksweep guy running? 
GEM_TEMPOBJ_POMGEN_PRUNE_ON_VOTE only dumps the pomgen on the floor ... 
a stale direct reference to one of these in the the TOC can also keep 
these guys alive ... I think that was why I marveled in the earlier 
message about it only being 32 instances ... with the referencePath 
method not finding anything you should be able to declare a victory:)

With a dynamic system it is difficult to get a complete answer without 
shutting things down, so you have to settle for approximate answers ..

For these 32 sessions, perhaps you should snapshot the extents[1] and 
verify that the objects will go away in a separate sandbox stone so that 
you will not perturb production while satisfying your curiousity...

[1] 
http://downloads.gemtalksystems.com/docs/GemStone64/3.2.x/GS64-SysAdmin-3.2/9-BackupAndRestore.htm#pgfId-1069325

Dale
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150706/df6adadd/attachment-0001.html>