[Glass] Backup procedure

[Dale Henrichs via Glass]

Yeah, the support code surrounding GEM_TEMPOBJ_POMGEN_PRUNE_ON_VOTE has 
evolved over time ...

Back in 2.4.x when the original problem with seaside gems was 
discovered, I think that there might have been a few bugs in the 
implementation of GEM_TEMPOBJ_POMGEN_PRUNE_ON_VOTE that lead to the 
initial recommendation of cycling gems (that way you get 100% 
GEM_TEMPOBJ_POMGEN_PRUNE_ON_VOTE). Also the max value of 
GEM_TEMPOBJ_POMGEN_PRUNE_ON_VOTE was limited to 90%, so there was quite 
a bit of room for some references to be kepts around. Here's the comment 
about GEM_TEMPOBJ_POMGEN_PRUNE_ON_VOTE from the 2.4.4.1 
$GEMSTONE/data/system.conf file:

#=========================================================================
# GEM_TEMPOBJ_POMGEN_PRUNE_ON_VOTE: Percent of pom generation area
#   to be thrown away when voting on possible dead objects.
#   Only subspaces of pom generation older than 5 minutes are thrown away.
#   The most recently used subspace is never thrown away.
#
# If this value is not specified, or the specified value is out of range,
# the default is used.
#
# Runtime equivalent: #GemPomGenPruneOnVote
# Default: 50
#    min: 0  max: 90
# GEM_TEMPOBJ_POMGEN_PRUNE_ON_VOTE = 50;


Overtime the implementation has been changed to the point where you are 
allowed to specify a GEM_TEMPOBJ_POMGEN_PRUNE_ON_VOTE of 100% so  the 
need to cycle gems can be completely eliminated. Here's the comment from 
the $GEMSTONE/data/system.conf file for 2.4.6 (3.3 is identical):

#=========================================================================
# GEM_TEMPOBJ_POMGEN_PRUNE_ON_VOTE: Percent of pom generation area
#   to be cleared when voting on possible dead objects.
#   If value is > 0 and < 100, subspaces of pom generation older
#   than 5 minutes are cleared; the number of subspaces cleared is
#   the specified percentage of spaces in use rounded down to an
#   integral number of spaces.
#   If value == 100, all subspaces of pom generation are cleared without
#   regard to their age.
#
# If this value is not specified, or the specified value is out of range,
# the default is used.
#
# Runtime equivalent: #GemPomGenPruneOnVote
# Default: 50
#    min: 0  max: 100
# GEM_TEMPOBJ_POMGEN_PRUNE_ON_VOTE = 50;

So for the semantics that applies to your version take a look at the 
$GEMSTONE/data/system.conf in your product tree ...

With regards to GemTools, tODE and topaz, Johan is correct you don't 
want to stay logged into a production system for very long or you may 
will see excessive extent growth ... the stone has to keep around ALL of 
the meta data (Commit Record Backlog) for all of the commits between you 
last abort and the current transaction ... for systems with high commit 
rates the commit record backlog can climb pretty quickly ...

Dale

On 06/08/2015 11:35 AM, Johan Brichau via Glass wrote:
>
>> You mean you do not even ever stop/start seaside gems??? mmmmmm
>
> Nope. Only when they crash ;)
>
>>     I have not figured out why the servicevm is behaving different in
>>     our case because the flag is set for all gems.
>>
>>
>> Did you check if one of the gems is fired linked while the others 
>> don't? if so, then you may be getting the flags of the gem.exe rather 
>> than the one of the seaside gems (I had this issue in the past)
>
> I checked. Does not seem to be the case.
> It’s a mystery (for now :)
>
>>     I never experienced a voting issue though, except if I
>>     accidentally launched another MFC concurrently. I don’t know but
>>     maybe a backup also blocks the voting process for an MFC? I think
>>     the manual mentions the conditions of the voting though.
>>
>>
>> mmmm in my case I THINK that the one gem that was opened and 
>> rejecting the MFC because of voting was actually gemtools...not 
>> seaside gems. So...I guess I am stopping the gems while MFC just to 
>> be super sure it will be fine and the MFC takes little time so far. …
>
> Ha yes. I think gemtools also causes that.
> But mind that leaving a gemtools open without interaction for a long 
> time while seaside is serving requests will also grow your transaction 
> backlog. So I never leave gemtools connected for a long time.
>
> cheers,
> Johan
>
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass

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