Bug 44617

Bug: 44617

Impact:

Informational

Product:

GemStone/S 64 Bit

Versions:

3.7.1, 3.7, 3.6.8, 3.6.7, 3.6.6, 3.6.5, 3.6.4, 3.6.3, 3.6.2, 3.6.1, 3.6, 3.5.8, 3.5.7, 3.5.6, 3.5.5, 3.5.4, 3.5.3, 3.5.2, 3.5.1, 3.5, 3.4.5, 3.4.4, 3.4.3, 3.4.2, 3.4.1, 3.4, 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.1, 3.2, 3.1.0.6, 3.1.0.5, 3.1.x

Platform:

All

Fixed In:

CR backlog during write-set union sweep

To make sure necessary information is preserved, the stone "pins" the commit record in effect at the start of the Admin Gem write-set union sweep during garbage collection (stone stat GcVoteState = 4) and prevents this commit record from being disposed until the sweep is completed.  Normally the sweep completes quickly, but if the number of possible dead (stone stat PossibleDeadObjs) and the size of the write-set union (stone stat GcWsUnionSize) are high, then a CR backlog may develop.

Note that this is independent of the commit record actually held by the Admin Gem itself, so the GcGem may not be reported as holding the oldest commit record (stone stats OldestCrSession, OldestCrSessNotInTrans).

Workaround

Reducing the time it takes to complete the write set union sweep, and the commit rate while it is running, will allow you to avoid problems.

Running markForCollection more frequently will result in smaller result sets that will allow faster write set union sweep.  Time markForCollection to allow the sweep to run during periods of no or light application load.  Configure the sweep to use as many sessions as your environment can support, using the following instructions:

You begin by specifying a maximum number of threads allowed by executing and committing as GcUser:

UserGlobals at: #sweepWsUnionMaxThreads put: X

Where X is the maximum allowed value between 1 and 8.

Next, you'll need to shutdown and restart the Admin GcGem so it picks up the new value:

System stopAdminGcSession. System startAdminGcSession.

Once the new Admin Gcgem is running, check the number of *actual* threads using:

SystemRepository mtThreadsLimit: <sessionId>

Where <sessionId> is the session ID of the Admin GcGem.

You can then adjust this dynamically up-and-down (to the max specified) by using:

SystemRepository mtThreadsLimit: <sessionid> setValue: X

WARNING:  having additional threads running may adversely impact system performance -- monitor carefully and be prepared to reduce the thread count if the load becomes too high.