-
Type: Bug
-
Resolution: Duplicate
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Admin, Diagnostics
-
None
-
ALL
-
Query 2017-06-19
Based on this thread, v3.0 should include initial locking time in total operation latency: https://groups.google.com/forum/#!searchin/mongodb-dev/mark$20callaghan%7Csort:date/mongodb-dev/l2fR4Xr-Bxo/ibYPp7BB4-cJ
However, this is not true. As an example, here is a log line of an operation that claims latency of 2ms, but it waited 1.5sec for a lock:
query ... query: { .... } planSummary: IXSCAN { venueId: 1, timestamp: 1, activeCommand: 1 } ntoreturn:100 ntoskip:0 nscanned:31 nscannedObjects:31 keyUpdates:0 writeConflicts:0 numYields:1 nreturned:31 reslen:6475 locks:{ Global: { acquireCount: { r: 4 } }, Database: { acquireCount: { r: 2 }, acquireWaitCount: { r: 1 }, timeAcquiringMicros: { r: 1468984 } }, Collection: { acquireCount: { r: 2 } } } 2ms
- duplicates
-
SERVER-29304 Exclude time spent blocking for awaitData from latency metrics
- Closed
- is duplicated by
-
SERVER-20632 Query execute time not include some LOCK acquire time
- Closed