-
Type:
Question
-
Resolution: Done
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
hi
my applicaton use secondary as a read concern of mongodb.
when i import lots of documents , developer notify me that their queries time out.
so ,i get some slowlog form errlog as follows :
-----------------------------------------------------------------------------------------------------
2017-09-26T09:02:09.722+0800 I COMMAND [conn1680898] command
db.table command: find { find: "table", filter: { sid: { $in: [ "x", "y", "z"] } }, projection: { _id: 0, bssid: 1, loc: 1, accuracy: 1 } }
planSummary: IXSCAN { sid: 1 } keysExamined:6,docsExamined:3 cursorExhausted:1 numYields:0 nreturned:3 reslen:959
locks:{ Global: { acquireCount: { r: 2 }, acquireWaitCount: { r: 1 }, *+timeAcquiringMicros: { r: 12923929+* } }, Database: { acquireCount: { r: 1 } }, Collection: { acquireCount: { r: 1 } } } protocol:op_query 12933ms
--------------------------------------------------------------------------------------------------------
we can see locks section, timeAcquiringMicros is 12923929. wait time is so long.
As we known lock of WiredTiger is document level , why a query wait so long .
seeing from db.currentOp(), as following:
---------------------------------------------------------------------------------------------------------
"desc" : "rsSync",
"threadId" : "140284498736896",
"active" : true,
"opid" : 7,
"secs_running" : 3118,
"microsecs_running" : NumberLong("3118657970"),
"op" : "none",
"ns" : "local.replset.minvalid",
"query" : {
},
"numYields" : 0,
"locks" : {
"Global" : "W"
},
"waitingForLock" : true,
"lockStats" : {
"Global" : {
"acquireCount" : {
"r" : NumberLong(258933),
"w" : NumberLong(518376),
"R" : NumberLong(1),
"W" : NumberLong(129595)
},
"acquireWaitCount" : {
"W" : NumberLong(68687)
},
"timeAcquiringMicros" : {
"W" : NumberLong(51701628)
}
},
-----------------------------------------------------------------------------------------------
the rssync thead holds a global lock, and lockstats.Global.acquireCount.W is bigger and bigger。
so , the root case is the rssync thead holds global lock .
I use ycsb to benchmark a new replset reproduce this case. And monitor of global lock is high.
- is related to
-
SERVER-31399 repl.apply.batches.totalMillis does not record the time spent applying batches
-
- Closed
-
- related to
-
SERVER-21858 A high throughput update workload in a replica set can cause starvation of secondary reads
-
- Closed
-
-
SERVER-20328 Allow secondary reads while applying oplog entries
-
- Closed
-