[Glass] Backup procedure

[Dale Henrichs via Glass]

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 
> <mailto: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 ...

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