[Glass] reclaim before migrating
Otto Behrens
otto at finworks.biz
Tue Oct 25 03:51:20 PDT 2022
PS. The reclaim gem's log reports the following settings:
[Info]: Startup configuration:
reclaimMinPages = 40 Pages.
reclaimMinFreeSpaceMb = 0 Megabytes.
deferReclaimCacheDirtyThreshold = 90 %.
sleepTimeBetweenReclaimMs = 0 Milliseconds.
sleepTimeWithCrBacklogMs = 0 Milliseconds.
reclaimDeadEnabled = TRUE.
objsMovedPerCommitThreshold = 2000 Objects.
deadObjsReclaimedCommitThreshold = 2000 Objects.
maxTransactionDuration = 300 Seconds.
reclaimVerboseLogging = 0 .
We are calling
System deadNotReclaimedCount
and
System scavengablePagesCount
to check if there's more objects that need reclaiming. Is this the right
way?
Thanks!
Otto Behrens
+27 82 809 2375
[image: FINWorks]
[image: FINWorks] <http://za.linkedin.com/in/waltherbehrens>
www.finworks.biz
Disclaimer & Confidentiality Note: This email is intended solely for the
use of the individual or entity named above as it may contain information
that is confidential and privileged. If you are not the intended recipient,
be advised that any dissemination, distribution or copying of this email is
strictly prohibited. FINWorks cannot be held liable by any person other
than the addressee in respect of any opinions, conclusions, advice or other
information contained in this email.
On Tue, Oct 25, 2022 at 12:38 PM Otto Behrens <otto at finworks.biz> wrote:
> Hi,
>
> When we do migrations in our GemStone 3.6.5 databases, we sometimes do
> some cleanup before we start migrating because we discovered some loose
> ends before the release. This creates dead objects; then we have to ensure
> that the dead objects are garbage collected because our migration process
> picks up any object that can be migrated.
>
> This process takes the system offline and we can then stop any "user"
> level gems / topaz sessions. This helps to get migrations to run reliably
> through.
>
> I am assuming the best way is to do a full markForCollection and reclaim
> before we start listing objects that should be migrated. Is this a
> reasonable approach?
>
> We run SystemRepository reclaimAll after the markForCollection. We then
> try to wait for all dead objects to be collected, but dead objects are
> still in the repository. We use
>
> SystemRepository findReferencePathToObject: (Object _objectForOop: xxx)
>
> and then get
>
> *** Scan completed *** (object is dead) Total time is 5 seconds
>
> Is there a way to synchronously wait until the space used by dead objects
> has been reclaimed? (and the object would not be picked up by
> listInstances). This assumes that the only way to really know if an object
> has been removed is if the space has been reclaimed. Or is there another
> approach that will work?
>
> Regards
>
> Otto Behrens
>
> +27 82 809 2375
> [image: FINWorks]
> [image: FINWorks] <http://za.linkedin.com/in/waltherbehrens>
> www.finworks.biz
>
> Disclaimer & Confidentiality Note: This email is intended solely for the
> use of the individual or entity named above as it may contain information
> that is confidential and privileged. If you are not the intended recipient,
> be advised that any dissemination, distribution or copying of this email is
> strictly prohibited. FINWorks cannot be held liable by any person other
> than the addressee in respect of any opinions, conclusions, advice or other
> information contained in this email.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/archives/glass/attachments/20221025/0bb9f878/attachment.htm>
More information about the Glass
mailing list