Bug 33298

Bug: 33298

Impact:

Product:

GemStone/S

Versions:

6.7.2.1, 6.7.2, 6.7.1, 6.7, 6.6.5, 6.6.4, 6.6.3.3, 6.6.3.2, 6.6.3, 6.6.2, 6.6.1, 6.6, 6.5.8, 6.5.7.5, 6.5.7, 6.5.6, 6.5.5, 6.5.4, 6.5.2, 6.5.1, 6.5, 6.3.1, 6.3, 6.2.x, 6.2, 6.1.6, 6.1.5, 6.1.x, 6.0.x, 5.1.5.1

Platform:

All

Fixed In:

restoreReclaimPages ties up pages until next tranlog

The command SystemRepository>>restoreReclaimPages generates a commit to
record its results.  A few additional pages are used in recording that
commit record.  But the pages reclaimed, together with the pages in
the commit record,  do not become available to the system until the
stone disposes that commit record.

Unfortunately, the stone doesn't actually process commit records unless
actively replaying a tranlog or the system exits restore mode and is
brought on-line.  So repeated use of restoreReclaimPages will tie up more
and more pages in the associated commit records until the next tranlog is
replayed.  In systems that repeat restoreReclaimPages while waiting for
the next tranlog, you can actually run out of free pages when you might
be expecting to get some back.

Workaround

Either limit the number of iterations of restoreReclaimPages used between
two tranlog restores, or use statmonitor/vsd to monitor the available
FreePages, and stop using restoreReclaimPages when the value becomes too low.