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

Exclude time spent blocking for awaitData from latency metrics

    XMLWordPrintable

Details

    • Improvement
    • Status: Closed
    • Major - P3
    • Resolution: Fixed
    • None
    • 3.5.9
    • Diagnostics, Querying
    • None
    • Fully Compatible
    • v3.4
    • Query 2017-06-19

    Description

      When a getMore is issued against a tailable cursor with the awaitData option and no results are currently available, the thread executing the getMore will wait on a condition variable for additional results to become available via insertion into the capped collection. This allows clients to periodically poll a capped collection for new records.

      This waiting time is currently incorporated into some of the latency measurements surfaced by the server (e.g. in diagnostic logs, the system.profile collection, and the opLatencies section of serverStatus). This can be counter-intuitive to users, since reporting on average latency may be skewed by this "expected" waiting time on systems that are mostly idle. Therefore, we should exclude this "expected latency" from the following:

      • system.profile
      • slow query logs
      • top
      • global operation latency histogram
      • per-collection operation latency histogram

      Note, however, that this behavior change will not apply to db.currentOp()'s secs_running or microsecs_running, since this output is more often used to gauge the true latency of active operations, rather than generating reports after the fact.

      Attachments

        Issue Links

          Activity

            People

              david.storch@mongodb.com David Storch
              david.storch@mongodb.com David Storch
              Votes:
              0 Vote for this issue
              Watchers:
              14 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: