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

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

    • Type: Icon: Bug Bug
    • Resolution: Done
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: 3.2.0
    • Component/s: Querying
    • Query
    • ALL

      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.

            Assignee:
            backlog-server-query Backlog - Query Team (Inactive)
            Reporter:
            aborunov Andrey Borunov
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: