[Glass] Garbage Collection , maintenance gem and typical seaside app

[Dale Henrichs]

On Thu, May 8, 2014 at 8:24 AM, Mariano Martinez Peck <marianopeck at gmail.com
> wrote:

> Hi GemStoners,
>
> I tried not to pay attention that much in the first steps on my GemStone
> project. But now, it is time to investigate this. I have read all the
> chapters about GC, but I have a few questions.
>

The whole GLASS setup has been aimed at _allowing_ you to defer these
decisions until you need to:)


>
> From what I understand, I am running one admingcgem and one reclaimgcgem
> which start automatically with the stone. Since my repository/app is still
> small, I think that's enough for the moment.
>
> Now, what what I understand, the reclaim part is worthless if there is no
> "mark" part. I do know I have #markForCollection, but the first question
> is:  Does GemStone ever run internally/automatically a full mark pass? Like
> in Pharo..like besides having #garbageCollection, Pharo itself sometimes
> run the GC. So...GemStone does that or if I don't invoke it (as a
> sysadmin), it will never be?
>

Agree with James ...

>
> GLASS comes with nice seaside scripts to start/stop gems and also a
> maintenance gem which calls WAGemStoneMaintenanceTask. This class, from
> what I can see, it does seaside session expiration and MFC. So....second
> question... if I have this VM running...then I wouldn't need to explicitly
> run a MFC as part of a cron job, right?
>

"Need to.." no, however, running an MFC once an hour can have a negative
impact on performance while it is running especially if your repository
size is significantly larger  than your SPC. During an MFC "all" of the
pages containing live objects are loaded into the SPC, which can end up
pre-empting pages that your "normally running" application will have to
load back into the SPC ... if you or your users notice that the system
responding sluggishly during MFC, then it is time to consider moving the
MFC from the maintenance vm to a separate cron job, so that you can control
when the mfc runs and avoid having the MFC run during peak hours.

>
> I have been facing/reading a problem in which some seaside gems (or
> maintenance VM) could hold into objects preventing them from being GCed. As
> a workaround, Dale suggested to reset gems every in a while or increase the GEM_TEMPOBJ_POMGEN_PRUNE_ON_VOTE=90; which in my case it is already 90. So
> ok...imagine I have a daily script / cron that resets all seaside gems and
> maintenance gem. That's all I would have to do right? because soon after
> (less than 1 hours), my maintenance gem will run MFC and then at some point
> the reclaim GC will do their work. I am correct?
> Even if that's try, if I run the "reset" of the seaside gems at a strange
> hour (like 4 am), I may want to even force a MFC and a #reclaimAll, right?
> Even if I know they would happen automatically in the future, I may prefer
> to pay its cost/time at 4 am. Would this make sense?
>

Technically the mfc runs immediately upon starting the maintenance vm (and
you can change that if you want).


>
> Finally...what's your opinion about epochGC for a typical Seaside app? I
> know there is a lot of trade-offs and it depends on the app...but as a
> general option, I found it strange to be disabled by default in GLASS.
>

When you are running an MFC once an hour an epochGC is not needed. If you
start running the MFC less frequently, then you want to keep an eye on
repository growth (especially if using a limited repository sized key file
or have your extents on disks without a lot of free space) ... If the
repository is growing larger than you'd like between MFCs and you do not
want to run the MFC more frequently, then the epochGC is the solution for
you ...

Dale

>
> Thanks for the clarification,
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20140508/b6b78800/attachment.html>