Details
-
Bug
-
Status: Closed
-
Major - P3
-
Resolution: Duplicate
-
2.2.0-rc0
-
None
-
None
-
linux and osx
-
ALL
Description
First noticed this in the http console, but repro'd in the shell.
Open two different connections to mongod with and insert a million simple docs:
> for (i = 0; i < 1000000; i++) { db.foo.insert({x:i}); }
|
From a third shell, filter the currentOp output:
> while ( 1 ) { db.currentOp().inprog.filter(function(x) { if ( x.secs_running == 1271310 ) { printjson(x); } } ) }
|
You should see lots of ops reported with the bad secs_running value:
{
|
"opid" : 783608,
|
"active" : true,
|
"secs_running" : 1271310,
|
"op" : "insert",
|
"ns" : "",
|
"query" : {
|
|
},
|
"client" : "127.0.0.1:54088",
|
"desc" : "conn14",
|
"threadId" : "0x112460000",
|
"connectionId" : 14,
|
"locks" : {
|
"^" : "w",
|
"^foo" : "W"
|
},
|
"waitingForLock" : false,
|
"numYields" : 0,
|
"lockStats" : {
|
"timeLockedMicros" : {
|
|
},
|
"timeAcquiringMicros" : {
|
"r" : NumberLong(0),
|
"w" : NumberLong(3)
|
}
|
}
|
}
|
secs_running is calculated by subtracting curTimeMicros64() value from the _start recorded for the currentOp (another call to curTimeMicros64()) in curop.h – perhaps the current time value is less than the _start value causing some overflow issue?
Attachments
Issue Links
- duplicates
-
SERVER-4740 Use monotonic clock sources for Timer
-
- Closed
-
- related to
-
-
- Closed
-