Uploaded image for project: 'Documentation'
  1. Documentation
  2. DOCS-13797

Investigate changes in SERVER-47155: Limit the number of simultaneous index builds running from user connections to 3

    XMLWordPrintable

    Details

    • Type: Task
    • Status: Open
    • Priority: Major - P3
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 4.4.0-rc0, 4.7.0
    • Component/s: manual, Server
    • Labels:
      None

      Description

      Description

      Downstream Change Summary

      Existing, undocumented behavior as of 4.2.3 and 4.4.0:
      In an attempt to bound memory usage and resource utilization, the server limits on the number of concurrent index builds started by a user on a primary node to 3.

      New behavior (as of 4.4.0 only):
      Any index builds started over the limit will block until the number of concurrent index builds drops below the limit. The log message "Too many index builds running simultaneously, waiting until the number of active index builds is below the threshold" (ID 4715500) will be logged when the limit is reached and an index build has blocked.

      This default limit can be raised with the maxNumActiveUserIndexBuilds setParameter. This can be changed at startup or runtime.

      Description of Linked Ticket

      Each index build is allowed to use up to 200MB of memory outside of the WT cache by default. This is controlled by maxIndexBuildMemoryUsageMegabytes. In an attempt to bound memory usage and reduce WT cache pressure, we limit the number of concurrent index builds started by a user on a primary node.

      Any index builds started over the limit will block until the number of concurrent index builds drops below the limit. The log message "Too many index builds running simultaneously, waiting until the number of active index builds is below the threshold" (ID 4715500) will be logged when the limit is reached and an index build has blocked.

      This default limit can be raised with the maxNumActiveUserIndexBuilds setParameter. This can be changed at startup or runtime.

      Original Description

      Both the primary and secondary nodes will have an unlimited thread pool size. This is done to allow secondary nodes to startup as many index builders as necessary in order to prevent scheduling deadlocks during initial sync or oplog application.

      When commands are run from user connections that need to create indexes, those commands will hang until there are less than 3 running index builder threads, or until the operation is interrupted.

       

      Scope of changes

      Impact to Other Docs

      MVP (Work and Date)

      Resources (Scope or Design Docs, Invision, etc.)

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned
              Reporter:
              backlog-server-pm Backlog - DB Eng Program Management Team
              Participants:
              Last commenter:
              Backlog - DB Eng Program Management Team
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Dates

                Created:
                Updated:
                Days since reply:
                11 weeks, 5 days ago
                Date of 1st Reply: