Uploaded image for project: 'Documentation'
  1. Documentation
  2. DOCS-14927

Investigate changes in SERVER-54571: queryHash and planCacheKey Fields Absent in getMore Requests

      Downstream Change Summary

      This change adds the "queryHash" and "planCacheKey" fields to the slow query log lines for getMore commands, as well as to the profiler entries for these getMores.

      Description of Linked Ticket

      Hi Team,

      Starting in v4.2, MongoDB introduced the queryHash and planCacheKey that respectively help identify slow queries with the same query shape and the plan cache entry associated with the query.

      Said fields are present in the log from the initial batch for a "slow" query:

      {
        "type": "command",
        "ns": "test.foo",
        "appName": "MongoDB Shell",
        "command": {
          "find": "foo",
          "filter": {
            "a": 1
          },
          "lsid": {
            "id": {
              "$uuid": "564cec84-a387-4fa5-9f50-97eafe97efde"
            }
          },
          "$db": "test"
        },
        "planSummary": "IXSCAN { a: 1 }",
        "cursorid": 8918754329959567000,
        "keysExamined": 101,
        "docsExamined": 101,
        "numYields": 0,
        "nreturned": 101,
        "queryHash": "4B53BE76",
        "planCacheKey": "100FCEBA",
        "reslen": 3825,
        "locks": {
          "ReplicationStateTransition": {
            "acquireCount": {
              "w": 1
            }
          },
          "Global": {
            "acquireCount": {
              "r": 1
            }
          },
          "Database": {
            "acquireCount": {
              "r": 1
            }
          },
          "Collection": {
            "acquireCount": {
              "r": 1
            }
          },
          "Mutex": {
            "acquireCount": {
              "r": 1
            }
          }
        },
        "storage": {
          "data": {
            "bytesRead": 2013,
            "timeReadingMicros": 3
          }
        },
        "protocol": "op_msg",
        "durationMillis": 1
      }
      

      But are absent from any subsequent getMore requests:

      {
        "type": "command",
        "ns": "test.foo",
        "appName": "MongoDB Shell",
        "command": {
          "getMore": 8918754329959567000,
          "collection": "foo",
          "lsid": {
            "id": {
              "$uuid": "564cec84-a387-4fa5-9f50-97eafe97efde"
            }
          },
          "$db": "test"
        },
        "originatingCommand": {
          "find": "foo",
          "filter": {
            "a": 1
          },
          "lsid": {
            "id": {
              "$uuid": "564cec84-a387-4fa5-9f50-97eafe97efde"
            }
          },
          "$db": "test"
        },
        "planSummary": "IXSCAN { a: 1 }",
        "cursorid": 8918754329959567000,
        "keysExamined": 276,
        "docsExamined": 276,
        "cursorExhausted": true,
        "numYields": 0,
        "nreturned": 276,
        "reslen": 10474,
        "locks": {
          "ReplicationStateTransition": {
            "acquireCount": {
              "w": 1
            }
          },
          "Global": {
            "acquireCount": {
              "r": 1
            }
          },
          "Database": {
            "acquireCount": {
              "r": 1
            }
          },
          "Collection": {
            "acquireCount": {
              "r": 1
            }
          },
          "Mutex": {
            "acquireCount": {
              "r": 1
            }
          }
        },
        "storage": {},
        "protocol": "op_msg",
        "durationMillis": 0
      }
      

      This happens for both find and aggregate operations in both v4.2.12 and v4.4.4.

      It would be nice to have these fields present in the getMore requests as not having them makes troubleshooting more difficult and/or inaccurate when using those fields as an analysis criteria, for example:

      1. We might miss the getMore requests.
      2. We might miss a query shape in its entirety if the first batch is slow and the slowness is only observed in subsequent getMore requests.

      Regards
      Diego

            Assignee:
            jason.price@mongodb.com Jason Price
            Reporter:
            backlog-server-pm Backlog - Core Eng Program Management Team
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved:
              2 years, 22 weeks, 3 days ago