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

send query in the secondary to query for very little data have same time is very slowly

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None
    • Operating System:
      ALL

      Description

      hi

          we have a problem when we send query same litter data collections in secondary always appear same very slowly query problems ,every day about one or two times.in the slowly logs we could find the timeAcquiringMicros take the longest time in the query.i think if always appear this problem .maybe we can't use secondary as one of the query point for share the responsibility of primary .because this will block  the query too long time.and let our program became dead.maybe in this time the  ParallelBatchWriterMode is PBWM 

       

      the log like this 

      2019-10-12T07:34:50.684+0800 I COMMAND [conn1279777] command gacc.r_plugin command: find { find: "r_plugin", filter:

      { type: "h3c" }

      , limit: 1, shardVersion: [ Timestamp 0|0, ObjectId('000000000000000000000000') ] } planSummary: IXSCAN { type: 1 } keysExamined:1 docsExamined:1 cursorExhausted:1 numYields:0 nreturned:1 reslen:350 locks:{ Global: { acquireCount:

      { r: 2 }

      , acquireWaitCount: { r: 1 }, timeAcquiringMicros: { r: 38560627 } }, Database: { acquireCount:{ r: 1 }}, Collection: { acquireCount:{ r: 1 }} } protocol:op_command 38560ms

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                zhouhancang hancang2000
                Participants:
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: