[Glass] Automatic increment policies of extent0.dbf size

[Trussardi Dario Romano via Glass]

Ciao Dale,

	thanks for your considerations.
> 
> 
> 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.

The system run markForCollection every hour as report into maintenance_gem.log :

	'Starting markForCollect.: 2015-11-13T16:56:42.91196393966675+01:00'
	--transcript--'Warning: markForCollection found 69407769 live objects, 404150 dead objects(occupying approx 36373500 bytes)'
	--transcript--'...finished markForCollect.2015-11-13T16:57:14.00137901306152+01:00'

and i don't have heavy loads running it ( in appearance ? what do you think about it ?)


> 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 ...

The relative 	ObjectLogEntry _objectLog size   report: 0

I think the system work without errors.

> 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 ...

The extent0.dbf  freeSpace decrease  about 50MB any day.

I have do some test cleanup the system by the old datas.

The target instances counted  before and after the cleanup with :

			SystemRepository countInstances: ( Array with: ClassA with: ClassB with: ClassC )

are right decrease after the cleanup and relative MFC cycle.

But with my surprise the SystemRepository freeSpace is not increase in proportion:
	
	i cleanup data for about to 40 days but the freeSpace is increase only of 100MB.

It's strange ?

> 
> 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 ...

Where i can read to do the upgrade?

My system is based on gsDevKitHome.	

> I hope this is what you were looking for,

I am interested to understanding what triggers and how it is managed the increase of the repository size.
	
What should I expect the next days, when the freeSpace go down? 

	Thanks,

		Dario


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20151113/9bb8c020/attachment-0001.html>