[Glass] extent0.dbf grows

[Dale Henrichs via Glass]

On 08/05/2015 02:33 PM, Mariano Martinez Peck wrote:
>
>
> On Wed, Aug 5, 2015 at 5:41 PM, Dale Henrichs via Glass 
> <glass at lists.gemtalksystems.com 
> <mailto:glass at lists.gemtalksystems.com>> wrote:
>
>
>
>     On 07/31/2015 08:58 AM, Trussardi Dario Romano via Glass wrote:
>>
>>     James,
>>
>>>
>>>>     On Jul 31, 2015, at 3:37 AM, Trussardi Dario Romano via Glass
>>>>     <glass at lists.gemtalksystems.com
>>>>     <mailto:glass at lists.gemtalksystems.com>> wrote:
>>>>
>>>>     Ciao,
>>>>
>>>>     i have a deployment system based on GemStone version '3.1.0.6'
>>>>
>>>>
>>>>     Now i use Gemtools and todeClient to do some works on the
>>>>     repository:  update code,  save repository .....
>>>>
>>>>
>>>>     When i login with the tools  i note the repository
>>>>     grows significantly, and also,the relative  full backups
>>>>     grows significantly.
>>>>
>>>>     To reset the system i need to clear the Object Log with the
>>>>     relative clear command  ( ol clearin tode )
>>>
>>>     Do you think that the Object Log grows significantly during your
>>>     time logged in with the tools? What is its size at the beginning
>>>     and end of your session?
>>
>>     I don't have real data about the extent0.dbf change size from
>>     beginning and end of a gemtools session.
>>
>>     But the full backup size  before Object Log  clear is : 4 258 529280
>>
>>     after Object Log clear is:1 376 124 928
>>
>>     The SystemRepository freeSpace size before Object Log clear is :
>>     1 092 419 584
>>
>>     after Object Log clear ( and one hour  of system background works
>>     )  is:  5 267 701 760
>>
>
>     Okay as James has mentioned, it definitely looks like the Object
>     Log is the source of the "excess data" ... it would be interesting
>     to understand what is in the object log ... My guess would be that
>     you are having recurring errors and the continuations created to
>     record those errors can easily cause a bunch of data to be stored
>     in your extent ... if the errors are providing useful data, than
>     this can be viewed as a "cost of doing business" and you will just
>     need to have a regularly scheduled task for clearing the object
>     log ... you could arrange to regularly clear continuation entries
>     from the object log that are more than a day or week or ? old then
>     at least you would expect to reach a steady state for extent size
>     ... then you would only need to consider shrinking the size of the
>     extent when you had an anomaly where a series of unexpected errors
>     cropped up ....
>
>
> I do exactly that as part of my daily cleaning:
>
>
> cleanObjectLogEntriesDaysAgo: aNumberOfDays
> | log |
> log := self objectLogEntries: true.
> (log select: [:ea | (Date today - ea stamp asDate) asDays >= 
> aNumberOfDays ]) do: [:ea | log remove: ea ifAbsent: []].
> System commitTransaction.
>
>
> objectLogEntries: shouldLock
>
> shouldLock
> ifTrue: [
> System writeLock: ObjectLogEntry objectQueue
> ifDenied: [
> Transcript show: 'ObjectLogEntry objectQueue lock denied'.
> ^ nil
> ]
> ifChanged: [
> System addToCommitOrAbortReleaseLocksSet: ObjectLogEntry objectQueue.
> Transcript show: 'ObjectLogEntry objectQueue lock dirty'.
> ^ nil
> ].
> System addToCommitOrAbortReleaseLocksSet: ObjectLogEntry objectQueue].
> ^ObjectLogEntry objectLog
>
>
> Maybe we could add this directly to class side of ObjectLogEntry so 
> that others can benefit from it?
If you could submit an issue with this code against GsDevKit[1] that 
would help me keep track ...

Even better a pull request against the glassdb/glass repo[2] would make 
sure that the code was immediately available ...

Since I see that James has some code as well, perhaps opening an issue 
would be best. We could discuss the code in more detail and perhaps 
incorporate the ideas from both of your scripts ...

Dale

[1] https://github.com/GsDevKit/GsDevKit/issues/new
[2] https://github.com/glassdb/glass/pulls
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150805/9094e478/attachment.html>