[Glass] extent0.dbf grows

[Mariano Martinez Peck via Glass]

On Fri, Jul 31, 2015 at 7:37 AM, Trussardi Dario Romano via Glass <
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 clear in tode )
>
>
> 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.
>
> 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 ?
>
>
Sometimes I found that keeping a GemTools session opened would complicate a
bit the voting of the MFC...so try to have at least GemTools off when
running MFC (in your case via WAGemStoneMaintenanceTask).
Also..note that depending on the size of the repository, the cpu, etc, the
MFC could take quite some time, affecting performance of current users. And
if you do it every hour it might be too much.

Also...for the conf file of the seaside gems, I recommend you either:

1) GEM_TEMPOBJ_POMGEN_PRUNE_ON_VOTE to 100%
(change  /opt/gemstone/product/seaside/etc/seaside30.conf in your case)
2) or recycle seaside gems before starting MFC (stop and start seaside gems
again)

Another thing I would take into account is enabling epochGC. See the admin
guide for details. But if you do so, then do not run MFC every hour since
it may be overkilling. I would do it..max...once  day...




>
> 2) to resize the extent i need to do a full backup and restoring into a
> virgin extent?
>
>
>
Yes, I do that, but not daily not even automatically. Once (with human
review) I note that my extent is much larger than it should normally need,
I shrink it. But note if you shrink it and then it needs to grow, the grow
operation is slow and hence has impact in current users. So... if you
extent free space goes and come back, do not shrink it. If the extent has a
lot of free space that doesn't seem to be used at any moment, and it is
significant, then I would shrink it (only if disk space is a problem).

I have made an script for compacting the extent which I shared it in this
thread:
http://forum.world.st/Cannot-make-full-backup-restore-to-work-tp4836094p4836237.html


> 3) there is possibility of directly reducing the extent file ?
>
>
Not that I am aware of.


>
> Thanks for any considerations,
>
>
> Dario
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150731/037984a6/attachment-0001.html>