-
Type:
Bug
-
Resolution: Incomplete
-
Priority:
Major - P3
-
None
-
Affects Version/s: 3.0.6
-
Component/s: GridFS
-
None
-
ALL
-
-
None
-
3
-
None
-
None
-
None
-
None
-
None
-
None
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