Details
-
Bug
-
Status: Closed
-
Major - P3
-
Resolution: Incomplete
-
3.0.6
-
None
-
None
-
ALL
-
Description
Issue happen on the secondary instance which we do some read operation on it , there are only around 200+ rows in fs.chunks and fs.files collections , our application counts both collections but it cost a long time to return result :
sample log :
2015-08-26T17:12:06.304+0800 I COMMAND [conn43] command UserFileSource.$cmd command: count { count: "fs.files", query: {} } planSummary: COUNT keyUpdates:0 writeConflicts:0 numYields:0 reslen:44 locks:{ Global: { acquireCount: { r: 2 }, acquireWaitCount: { r: 1 }, timeAcquiringMicros: { r: 272849 } }, Database: { acquireCount: { r: 1 } }, Collection: { acquireCount: { r: 1 } } } 272ms
|
2015-08-26T17:12:06.304+0800 I COMMAND [conn116] command ADFileSource.$cmd command: count { count: "fs.files", query: {} } planSummary: COUNT keyUpdates:0 writeConflicts:0 numYields:0 reslen:44 locks:{ Global: { acquireCount: { r: 2 }, acquireWaitCount: { r: 1 }, timeAcquiringMicros: { r: 160138 } }, Database: { acquireCount: { r: 1 } }, Collection: { acquireCount: { r: 1 } } } 160ms
|
db stats like this :
> db.stats()
|
{
|
"db" : "ADFileSource",
|
"collections" : 3,
|
"objects" : 490,
|
"avgObjSize" : 55058.23673469388,
|
"dataSize" : 26978536,
|
"storageSize" : 26263552,
|
"numExtents" : 0,
|
"indexes" : 8,
|
"indexSize" : 319488,
|
"ok" : 1
|
}
|
ADFileSource is not a big database , CPU usage is not high , so the bottleneck should not be the cpu.
Attached some status logs(dblog , serverstatus and iostats) for your analysis.
Any futher information please let me know .
Thanks
Carl