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

[Dale Henrichs]

For Seaside we know that there is a lot of persistent session state that
expires every 10 minutes (or whatever your expiry is) and is naturally
short-lived.

This is all about managing repository size and we know that there can be
significant repository growth due to session state (the magnitude of the
growth is dependent upon the number of requests per second)... so the
frequency of the epoch should be based upon how much repository growth you
are willing to live with ...

Epoch gc is not 100% effective in cleaning up short-lived objects. Those
objects whose lifetimes span the epoch boundaries are not going to be
collected by epoch gc, so the longer the period between epochs the higher
your effective rate.

For SS3 I think I run an MFC twice a day and run an epoch every hour and
for that site, the repository size stays pretty steady state ...

As a final note, you want to keep an eye on your Object Log ... if you have
a lot of continuations in your object log, you end keeping an even larger
number of objects alive ... it is a good practice to  remove the
continuations from your object log on a regular basis or simply clear the
object log on a regular basis...

Dale


On Thu, May 8, 2014 at 9:37 AM, Norm Green <norm.green at gemtalksystems.com>wrote:

> Well, it all depends on the usage pattern of the database.  Epoch GC is
> designed to cleanup short lived objects.  MFC is the global cleanup.
>
> Running epochs hourly or daily and running MFC during low times (weekends
> or middle of the night) are common practices.
>
> Norm
>
>
> On 5/8/14, 9:32, Otto Behrens wrote:
>
>> Thanks, so the MFC have become quite fancy. Very interesting.
>>
>> So when do I use the MFC (eg from cron / maintenance process) and when
>> do I use the epoch GC?
>>
>> On Thu, May 8, 2014 at 6:19 PM, Norm Green
>> <norm.green at gemtalksystems.com> wrote:
>>
>>> The MFC can be heavy-weight but is designed to be tunable so that it can
>>> also be very light-weight at the expense of taking more time to complete.
>>> This is done by tuning the number of threads used by the MFC and how much
>>> CPU those threads are allowed to consume.
>>>
>>> For example, in 3.x, running the MFC with 1 thread and a cpu limit of 10%
>>> should have minimal impact on the system:
>>>
>>> SystemRepository markForCollectionWithMaxThreads: 1 waitForLock: 60
>>> percentCpuActiveLimit: 10
>>>
>>> Of course you have to be careful not to limit resources too much else the
>>> MFC may never finish.
>>>
>>> Norm
>>>
>>>
>>>
>>>
>>> On 5/8/14, 9:08, Otto Behrens wrote:
>>>
>>>> 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?
>>>>>
>>>>>
>>>>> Right.
>>>>>
>>>> Sorry, I lied. The default maintenance30 implementation does an MFC
>>>> every hour. We disabled that in our apps and switched the epoch GC on.
>>>> I think the MFC is *extremely* heavyweight and will influence your
>>>> application when it runs on a DB with some data. I can't really give a
>>>> measure of how much "some" is, in other words when the DB is small
>>>> enough where the MGC will not influence it that much.
>>>>
>>>> I understand that the purpose of the epoch GC is to be a process that
>>>> runs in the background with loads of fancy parameters to throttle it.
>>>> A seaside app in my understanding is an ideal candidate app for the
>>>> epoch GC. We bypassed WAGemStoneMaintenanceTask >>
>>>> maintenanceTaskMarkForCollect such a long time ago that I forgot about
>>>> it. To me, it does not make sense to implement that complexity in
>>>> maintenanceTaskMarkForCollect if there is a much more sophisticated
>>>> and efficient tool around (epoch GC).
>>>> _______________________________________________
>>>> Glass mailing list
>>>> Glass at lists.gemtalksystems.com
>>>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>>>
>>>
>>> _______________________________________________
>>> Glass mailing list
>>> Glass at lists.gemtalksystems.com
>>> http://lists.gemtalksystems.com/mailman/listinfo/glass
>>>
>>
> _______________________________________________
> 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/967ab35d/attachment-0001.html>