[Glass] Automatic increment policies of extent0.dbf size

[Dale Henrichs via Glass]

On 11/13/15 6:10 AM, Trussardi Dario Romano via Glass wrote:
> Ciao,
>
> i have a 3.1.0.6 extent0.dbf  into deployment status.
>
> Some months ago when i work with Gemtools and Tode the repository go 
> up to *5991563264 byte,*
> with freeSpace of 5286739968.
>
> Now day after day the system freeSpace decrease of 50MB any day,
>
> and today the freeSpace  is about: 1311784960.
>
> Now my question is to understand ( in broad terms ) when and how the 
> repository size grow up.
>
> When and than my repository will increase the next time ?
>
> Thank for any considerations.
>
> Dario
>
>
>
The broad answer is that it depends upon your application ... You are 
using Seaside and Seaside stores session state as persistent objects. If 
you don't run the maintenance vm and expire the Seaside sessions 
(WAGemStoneMaintenanceTask class>>maintenanceTaskExpiration) on a 
regular basis then your data base will grow. Seaside also adds error 
continuations to the object log and this means that a copy of the 
process that was running at the time of the error is persisted so all 
temp vars and objects reachable form the process are persisted. If you 
don't periodically clean up the errors in your object log, then the 
object log could be another source of growth ...

I think that we had covered those two possibilities along with a couple 
of other recommendations in the previous email. If you are regularly 
running the session expiration and you are regularly pruning your object 
log and your db is growing, then it is likely that your data structures 
are the source of the growth and we would want to go through the process 
of a) characterizing the types of objects that are accumulating in the 
repository b) answer the question whether the accumulated objects are 
reasonable within the context of your application and if not then c) try 
to understand (Repository>>findReferencePathToObject: and friends) what 
is causing those objects to continue to live ...

In 3.2.x we have a better API for finding reference paths 
(Repository>>findAllReferencePathsToObject: and friends) so if it 
becomes difficult to find the meaningful reference path in 3.1.0.6, you 
could upgrade a copy of your extents to 3.2.x and use the 
findAllReferencesPathsToObject: variant ...

I hope this is what you were looking for,

Dale
GS64-GCI.book
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20151113/125012b1/attachment.html>