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

Expose time spent holding locks, excluding time spent waiting to acquire them

    XMLWordPrintableJSON

Details

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Major - P3 Major - P3
    • None
    • None
    • Diagnostics
    • None
    • Query Execution

    Description

      Since version 3.0, the latencies reported in the logs and profiler have generally represented the entire operation latency, including any time spent acquiring locks. We separately report lock wait times in the locks section of the logs, system.profile, and serverStatus. However, often it is interesting to analyze the time an operation takes without including lock acquisition. For example, in the case of queues on a lock caused by a slow operation, this would help to identify which operations are actually taking a long time for the execution path to process, as opposed to those taking a long time because they need a lock which is currently held by another op.

      If we decide to explicitly expose such a quantity, we should think through how to add it to the following debug mechanisms:

      • Slow query logs.
      • system.profile collection.
      • db.currentOp().
      • The top command.
      • Global and per-collection latency stats.
      • serverStatus().

      Attachments

        Activity

          People

            backlog-query-execution Backlog - Query Execution
            david.storch@mongodb.com David Storch
            Votes:
            0 Vote for this issue
            Watchers:
            11 Start watching this issue

            Dates

              Created:
              Updated: