Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-40058

AutoStatsTracker's lock acquisition to read the profiling level should not conflict with secondary batch application

    • Type: Icon: Improvement Improvement
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 4.1.9
    • Affects Version/s: None
    • Component/s: Concurrency
    • None
    • Fully Compatible
    • Query 2019-03-25
    • 0

      The AutoStatsTracker is used by various code paths to record operation counters in Top and to set the correct diagnostic information on the operation's CurOp. Amongst its jobs is to determine the profiling level associated with the operation, and set it on the CurOp. Since the profiling level can be configured on a per-database basis, and since this information is stored in-memory inside the catalog subsystem's Database object, this involves acquiring the appropriate MODE_IS intent lock on the database:


      As implemented, it is possible for this lock acquisition to conflict with parallel oplog batch application on secondary nodes. However, the MODE_IS database lock here is used solely to protect access to DatabaseImpl::_profile. Therefore, there is no need to conflict with batch application. Preventing such lock conflicts could increase throughput of operations that use the AutoStatsTracker. Many operations that use the AutoStatsTracker, such as secondary reads via the find command, are already configured to avoid conflicting with batch application inside AutoGetCollectionForRead:


      However, there are code paths which use the AutoStatsTracker but never use AutoGetCollectionForRead, causing unnecessary blocking during batch application while attempting to set the profiling level. This was observed in our performance testing infrastructure for the OP_KILL_CURSORS code path.

            david.storch@mongodb.com David Storch
            david.storch@mongodb.com David Storch
            0 Vote for this issue
            2 Start watching this issue