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

bulk key insertion phase of index build holds IX lock without yielding

    • Fully Compatible
    • ALL
    • v5.0, v4.4, v4.2
    • Execution Team 2021-07-26, Execution Team 2021-08-09
    • 137

      The key insertion phase of a hybrid index build seems to hold and not yield an IX (w) lock. Any single command with an S (R) lock can block all operations during that time. In this case the offending command seems to be the read-only profile command (profile: -1)

      original description

      hello:
      my mongo cluster is 4.2.8 with six data node.today i create index with follow command:

      db.monitorIn.createIndex({ org: 1.0, et: 1.0, pbOrg: 1.0 });
      

      index from 2020/10/22 09:58,to 10:30,all write is slow 10 times than before.it is :

      Database: { acquireCount: { w: 3 }, acquireWaitCount: { w: 1 }, timeAcquiringMicros: { w: 3908088 } }.run in Index Build: inserting keys from 
      external sorter into index mode,
      

      all write is blocking.

      2020-10-22T12:28:09.819+0800 I  INDEX    [conn997955] index build: inserted 439497660 keys from external sorter into index in 319 seconds.
      

      all write is blocked time :319

      from 2020-10-22T12:28:update time is 288831.

      2020-10-22T12:28:10.853+0800 I  WRITE    [conn1004545] update expMonitordb.expInfos appName: "monitor_in_out" command: { q: { _id: "YT4873152410671", $or: [ { curT: { $exists: false } }, { curT: { $lt: new Date(1603336989000) } } ] }, u: { $set: { curT: new Date(1603336989000), currentOrg: "454001", currentOp: 131 } }, multi: false, upsert: false } planSummary: IXSCAN { _id: 1 } keysExamined:1 docsExamined:1 nMatched:1 nModified:1 numYields:0 queryHash:DE51A53B planCacheKey:2FB486A3 locks:{ ParallelBatchWriterMode: { acquireCount: { r: 2 } }, ReplicationStateTransition: { acquireCount: { w: 2 } }, Global: { acquireCount: { w: 2 } }, Database: { acquireCount: { w: 2 }, acquireWaitCount: { w: 1 }, timeAcquiringMicros: { w: 288830662 } }, Collection: { acquireCount: { w: 2 } }, Mutex: { acquireCount: { r: 5 } } } flowControl:{ acquireCount: 1, timeAcquiringMicros: 1 } storage:{} 288831ms
      

        1. metrics.2020-10-21T19-47-05Z-00000
          9.93 MB
        2. metrics.2020-10-22T00-17-05Z-00000
          10.00 MB
        3. metrics.2020-10-22T04-31-37Z-00000
          9.99 MB
        4. metrics.2020-10-22T08-31-42Z-00000
          9.86 MB
        5. metrics.2020-10-22T12-31-43Z-00000
          1.03 MB
        6. Screen Shot 2020-10-26 at 10.01.53 AM.png
          Screen Shot 2020-10-26 at 10.01.53 AM.png
          95 kB
        7. Screen Shot 2020-11-03 at 2.27.31 PM.png
          Screen Shot 2020-11-03 at 2.27.31 PM.png
          94 kB
        8. Screen Shot 2021-02-26 at 14.53.11.png
          Screen Shot 2021-02-26 at 14.53.11.png
          98 kB
        9. Screen Shot 2021-03-26 at 18.25.10.png
          Screen Shot 2021-03-26 at 18.25.10.png
          60 kB
        10. shard1.log.tar.gz
          44.15 MB

            Assignee:
            yuhong.zhang@mongodb.com Yuhong Zhang
            Reporter:
            601290552@qq.com jing xu
            Votes:
            0 Vote for this issue
            Watchers:
            26 Start watching this issue

              Created:
              Updated:
              Resolved: