[Glass] Backup procedure

Mon Jun 8 12:41:47 PDT 2015

On Mon, Jun 8, 2015 at 4:27 PM, Dale Henrichs via Glass <
glass at lists.gemtalksystems.com> wrote:

>  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):
>
>

Hi Dale,

Thanks for telling us. Now, if you were to guess, would you prefer 1) to
stop/start the seaside gems and let a value of 90% or so... or 2) let 100%
and do not even start/stop gems?

Thanks in advance,

> #=========================================================================
> # 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 listGlass at lists.gemtalksystems.comhttp://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
>
> _______________________________________________
> 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/20150608/54e1b9ce/attachment-0001.html>