[Glass] Automatic increment policies of extent0.dbf size

[Paul DeBruicker via Glass]

I just had an out-of-disk error with another service that shares a disk with
my 3.3.1 stone because my extent0.dbf file had grown to ~23GB in size. 
After going through the "shrink the repository" procedure the extent is now
680MB.   


IS there a way to prevent the extent from growing indefinitely with empty
space or should I just make a plan to go through the "shrink the repo"
process on a regular basis?



Thanks


Paul






GLASS mailing list wrote
> 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
> 
> _______________________________________________
> Glass mailing list

> Glass at .gemtalksystems

> http://lists.gemtalksystems.com/mailman/listinfo/glass





--
View this message in context: http://forum.world.st/Automatic-increment-policies-of-extent0-dbf-size-tp4860811p4933940.html
Sent from the GLASS mailing list archive at Nabble.com.