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

Only use queuing metrics to calculate workingMillis

    • Type: Icon: Improvement Improvement
    • Resolution: Unresolved
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • None
    • Workload Scheduling
    • WS Prioritized List

      workingMillis is currently calculated as the total execution time for an operation minus the time "blocked" and time "waiting for tickets" (see here for more detail). The way this is calculated means we need to manually validate that the "blocked" and "waiting for tickets" time always reflect all the possible queues an operation could wait in.

      SERVER-88168 introduced the concept of a queues section of curOp/serverStatus, which calculates the totalTimeQueuedMicros for all possible queuing points in the gQueueMetricsRegistry. If we changed the workingMillis calculation to only consider queues in that registry, then ensuring workingMillis is correct becomes an issue of validating that the registry is comprehensive. This code would eventually be rewritten to (untested, but you get the gist):

          auto totalBlockedTime = [&]() {
              Microseconds totalTimeQueuedMicros{0};
              for (auto&& [queueName, lookup] : gQueueMetricsRegistry) {
                  AdmissionContext* admCtx = lookup(opCtx);
                  totalTimeQueuedMicros += admCtx->totalTimeQueuedMicros();
              }
              return totalTimeQueuedMicros;
          }();
          auto workingMillis = Milliseconds(executionTimeMillis) - totalBlockedTime;
      

            Assignee:
            Unassigned Unassigned
            Reporter:
            matt.broadstone@mongodb.com Matt Broadstone
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated: