[Glass] extent0.dbf grows

[itlists@schrievkrom.de via Glass]

How does the Zinc server behaves here ?


Assuming, that one has lots of GEMS running - some are Zinc HTTP
servers, others are simple topaz based servers.

And the topaz servers are running always and doing requests against the
stone (time scheduled in seconds intervals).

But consider a situation, where the Zinc servers do not get any external
requests for a long period of time (hours) ...

If the Zinc server is not written correctly, then this system may get
into trouble ... right ?

Have to look into the sources ...

Marten


Am 31.07.2015 um 16:33 schrieb James Foster via Glass:
> 
>> 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?
> 
>> After 1 hour ,  because i have active the #WAGemStoneMaintenanceTask 
>>
>> A) the system recovers the free space
>>
>> B) the relative full backups become small
>>
>> But now i have an extent0.dbf   of   5 991 563 264  with a freeSpace
>> of 5 267 701 760.
>>
>> It is not a very good situation.
> 
> Why? Having empty space in the repository (extents) isn’t really much
> worse than having empty (unused) space in the file system. 
> 
>> Questions:
>>
>> 1) what should I do with the tools to not increase the size of the
>> relative extent ?
>>
>> I need to operate with the tools  when the seasideGems30 are down ?
> 
> The most common cause of unexpected repository growth is a commit record
> (CR) backlog. If you log in a session and do not commit while other
> sessions do commits, then you get a CR backlog. You should ensure that
> each login, including tools, does a regular commit.
> 
>> 2) to resize the extent i need to do a full backup and restoring into
>> a virgin extent?
> 
> Yes.
> See https://downloads.gemtalksystems.com/docs/GemStone64/3.2.x/GS64-SysAdmin-3.2/GS64-SysAdmin-3.2.htm?https://downloads.gemtalksystems.com/docs/GemStone64/3.2.x/GS64-SysAdmin-3.2/7-RepositorySpace.htm#pgfId-82473.
> 
>> 3) there is possibility of directly reducing the extent file ?
> 
> Repository>>#’shrinkExtents’ might be worth a try, but it is so rarely
> useful that it has been deprecated.
> 
>> Thanks for any considerations,
>>
>>
>> Dario
> 
> James
> 
> 
> 
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
> 


-- 
Marten Feldtmann