Ah okay ... Yes an MFC on a repository that is larger than the SPC can result in noticeable performance issues for general users ...
You have a couple of choices:
1. schedule MFC during off hours
- avoid hitting users with MFC issues
2. run EpochGc to incrementally collect garbage
- this minimizes repository growth between MFCs
3. run offline gc (see FDC/MGC in manual)
- the scan is done in a separate stone/SPC and the production SPC
isn't perturbed by the scan for" disconnected objects". the mark step is
would still be performed in the production SPC
The "only cost" to running less frequent MFC (say on the weekends) is that your repository will grow larger ... EpochGc is a good option for Seaside, because the bulk of the persistent garbage is produced by Seaside session state and an hourly epoch will gc a good portion of the Seaside session garbage ... The garbage produced around Epoch boundaries is not caught by EpochGc and garbage produced by objects with a longer lifetime than the epoch will also not be caught, so it is necessary to still run periodic MFCs ...
On Sun, Jan 26, 2014 at 11:19 AM, Leo De Marco (Smalltalking) <[hidden email]> wrote:
I'm not getting any particular error. The problem is with some reports,
when the users use that functionality the system go down in performance.
I have a pending issue to review that’s reports, but in the meanwhile
it would be great to have a way to perform the clean cache script when
reach some number.
De: Dale Henrichs [mailto:[hidden email]] Enviado el: viernes, 24 de enero de 2014 15:42 Para:[hidden email] CC: GemStone Seaside beta discussion Asunto: Re: [Glass] gc related to cache size
I'm not familiar with the "cache is too big" condition .... what error message do you get?