[Glass] Backup procedure

[Mariano Martinez Peck via Glass]

On Mon, Jun 8, 2015 at 7:48 PM, Dale Henrichs <
dale.henrichs at gemtalksystems.com> wrote:

>
>
> On 06/08/2015 12:41 PM, Mariano Martinez Peck wrote:
>
>
>
> 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,
>
>
> If you're using a version of GemStone that supports the 100%  option then
> I'd be inclined to go that route ... starting and stopping gems just
> requires extra machinery and can interrupt users ... Now if I happen to
> have a gem or two that are doing batch processing and the potential for
> referencing a bunch of persistent objects I might think twice and consider
> the cost of restarting the (presumably long rnning) batch process and
> refilling the cache for those gems versus the amount of repository growth I
> might encounter ...
>
> With the ability to flush all persistent objects you're basically
> stopping/restarting with respect to POM ...
>
>
Ok, it makes sense your analysis. Thanks.
BTW....if I set 100% and I do not stop/start seaside gems, I am still fine
not restarting seaside maintenance vm AND i am also find with the backup
code (besides MFC)? I mean, won't the running seaside gems affect at all to
the backup? I guess not, but just want to confirm.



-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150609/02c80258/attachment.html>