Bug 24961

Bug: 24961

Impact:

Informational

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, 5.1.5

Platform:

All

Fixed In:

Increasing #mfcGcPageBufSize can have adverse effects

The release notes for GS/S 5.1.5 mention that increasing the size
of the markForCollection mark/sweep buffer can improve MFC
performance.  This is done by executing:

    (UserGlobals at: #mfcGcPageBufSize put: <NewBufferSize>)

in the session performing the markForCollection.  However, in
environments where the MFC session is subject to sigAborts,
increasing this parameter to too high a value can instead result
in poor sigAbort response times and degraded MFC performance.

If you perform markForCollection while other sessions are busy
committing transactions, and the MFC session is therefore subject
to periodic sigAborts, then excessively increasing the size of the
mark/sweep buffer can result in the following problems:

1.  Degraded sigAbort response time for the MFC session.  While
    gathering a batch of pages for mark/sweep processing, the
    session cannot respond to a sigAbort.  If the value of
    #mfcGcPageBufSize is too high, the delay for processing the
    sigAbort can result in the system suffering from a CR backlog,
    or in GemStone versions prior to 6.0.1, the MFC session failing
    with a lostOTRoot error.
2.  Poor MFC performance.  After gathering a batch of pages, the
    next step processes each page, marking and sweeping the objects
    on that page.  This step *is* sensitive to sigAborts, and will
    cancel all further processing of subsequent pages in this
    batch upon receipt of a sigAbort.  The remaining pages will
    have to be re-gathered in the next batch.  If the sigAbort was
    received during the page gathering phase, then *all* the work
    for this batch is abandoned and the pages will need to be
    re-gathered in the next batch.  This can result in the MFC
    session appearing to hang (the cache statistic ProgressCount
    does not change for an extended period of time) for as long
    as sigAborts keep interrupting the session.

Unfortunately, there is no easy way to determine the maximum safe
value for #mfcGcPageBufSize, as it will depend on your site
configuration and transaction loads.  We suggest you start with
a value of 500 (the default setting is 320), and gradually increase
it over subsequent MFC's, using VSD/statmonitor to monitor sigAbort
behavior (SigAbortCount and AbortCount) and MFC performance
(ProgressCount).