Bug 45925

Bug: 45925

Impact:

Product:

GemStone/S 64 Bit

Versions:

3.3.9, 3.3.8, 3.3.7, 3.3.6, 3.3.5, 3.3.4, 3.3.3, 3.3.1, 3.3, 3.2.16, 3.2.15, 3.2.14, 3.2.13, 3.2.12, 3.2.11, 3.2.10, 3.2.9, 3.2.8.1, 3.2.8, 3.2.7, 3.2.6, 3.2.5, 3.2.4, 3.2.3, 3.2.2, 3.2.x, 3.2, 2.4.8, 2.4.7, 2.4.6

Platform:

Fixed In:

3.4

STN_FREE_SPACE_THRESHOLD lower than GcUser #reclaimMinFreeSpaceMb can block reclaim

Reclaim activity is deferred when the free space on the system falls below the setting of the GcUser parameter #reclaimMinFreeSpaceMb.  If this value is higher than the STN_FREE_SPACE_THRESHOLD and the amount of free space on the system falls between the two values, the system can become "stuck" where the free space is below the #reclaimMinFreeSpaceMb (so reclaim activity is deferred) but above the STN_FREE_SPACE_THRESHOLD (so the stone never adds additional space).

During normal operation on a quiet system, this can cause reclaim activity to be deferred indefinitely until other system activity finally causes the free space to drop below the STN_FREE_SPACE_THRESHOLD.

During tranlog replay, since there's no other system activity to reduce the free space, reclaim will be deferred forever. This will cause the tranlog replay to hang until the 30 minute timeout expires and shuts down the stone.

Workaround

Keep the setting for reclaimMinFreeSpaceMb below the configuration setting for STN_FREE_SPACE_THRESHOLD.  Don't use the default reclaimMinFreeSpaceMb setting of zero, which causes the system to calculate a default value that will often be higher than the STN_FREE_SPACE_THRESHOLD.