CR backlog during write-set union sweep cannot be cleared
As described in bug 44617, a long-running write set union sweep may result in a commit record backlog, since the commit record current when the write set union sweep begins must be retained, and so is "pinned" in the stone.
If the Admin GcGem is terminated before the completion of the write-set union sweep, the commit record is still left pinned and the CR backlog will continue to develop. The only way to clear this is to shutdown and restart the stone, but when the Admin GcGem comes back on-line it will begin a new write-set union sweep and a new CR backlog will develop.
Workaround
Reducing the time it takes to complete the write set union sweep, and the commit rate while it is running, will allow the write set union sweep to run to completion and 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.
Last updated: 9/3/14