-
Type:
Improvement
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: Aggregation Framework, Diagnostics
-
Fully Compatible
-
v4.4, v4.2, v4.0
-
Query 2019-02-11, Query 2019-05-06, Query 2019-11-04, Query 2019-11-18, Query 2019-12-30, Query 2020-01-13, Query 2020-01-27, Query 2020-02-10, Query 2020-02-24, Query 2020-03-09, Query 2020-03-23, Query 2020-04-06, Query 2020-04-20, Query 2020-05-04
-
(copied to CRM)
-
35
Aggregation queries using $mergeCursors communicate with other shards and therefore can be affected by communication issues or issues on other nodes. In the following example the query ran for a very long time but did not spend any time acquiring locks and did not yield. Possibly it was waiting for a reponse from one or more of the other hosts, but there is no indication of that in the log message. It would be helpful for diagnosis if the slow query report indicated how much time was spent waiting for each host.
2017-06-23T06:53:15.357+0200 I COMMAND [conn44] command ... command: aggregate { aggregate: "...", pipeline: [ { $mergeCursors: [ { host: "...", ns: "...", id: 253733414549 }, ...]}, { $group: ... } keysExamined:0 docsExamined:0 numYields:0 nreturned:0 reslen:17527 locks:{ Global: { acquireCount: { r: 6 } }, Database: { acquireCount: { r: 3 } }, Collection: { acquireCount: { r: 2 } } } protocol:op_command 2909221ms
- causes
-
SERVER-53751 findMatchingLogLines js helper function doesn't work when command's log verbosity level is 2
-
- Closed
-
- is documented by
-
DOCS-13613 Investigate changes in SERVER-31368: Log time spent waiting for other shards in merge cursors aggregation stage
-
- Closed
-
- is related to
-
-
- Closed
-
- related to
-
-
- Closed
-
-
-
- Closed
-