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

CloneCollection with query doing COLLSCAN although there is an index on field

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Gone away
    • Affects Version/s: 3.2.0
    • Fix Version/s: None
    • Component/s: Querying
    • Operating System:
      ALL

      Description

      Hello!

      I have a capped collection with about 150 million documents in it (20 Gb of data). The insertion rate to this collection is about 500-100 doc/sec. I have an index on one of the fields - "start", which is a number. I perform scheduled cloneCollection from another mongod instance (both instances version is 3.2) with a query like {start: {$gt: <some number>}}. The cloneCollection command takes very long, about 10 minutes and is slowly increasing with every next cloneCollection.

      When I searched through the mongod.log, I found the entries like this:

      2015-12-25T16:09:53.073+0600 I QUERY    [conn2951] query statserver-collector.statrecords query: { query: { _id: { $gt: 165091491.0 } }, $snapshot: true } planSummary: COLLSCAN cursorid:22150682963 ntoreturn:0 ntoskip:0 exhaust:1 keysExamined:0 docsExamined:121741412 keyUpdates:0 writeConflicts:0 numYields:952128 nreturned:101 reslen:17236 locks:{ Global: { acquireCount: { r: 1904258 } }, Database: { acquireCount: { r: 952129 } }, Collection: { acquireCount: { r: 952129 } } } 339569ms
      

      I see the PlanSummary is COLLSCAN. As I understand, this means that the query is performing without an index, although there is an index on "start". When I type in mongo console the similar query:

      db.mycollection.find({_id: {$gt: 165091491}})
      

      the planSummary is IXSCAN and the query return rows very quickly.

      The main thing is: we downgraded MongoDB from 3.2 to 3.0.8 (only one instance, we cloneCollection from), and this issue just disappear. We didn't change our code, steps are the same, and cloneCollection now finish in a few seconds.

      So I think, the issue is somewhere in v3.2. I tried to search but didn't find any reported problems similar to this.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              backlog-server-query Backlog - Query Team
              Reporter:
              aborunov Andrey Borunov
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: