[SERVER-23456] high latency on simple mongo queries during map-reduce operations Created: 31/Mar/16 Updated: 01/Apr/16 Resolved: 01/Apr/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | MapReduce |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Question | Priority: | Major - P3 |
| Reporter: | pavan | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Participants: |
| Description |
|
Mongo-DB in spite of having adequate resources ( 4 - Core Box ) with single map-reduce operations seems to be chocking down other operations. In our simple tests , with simple collection having 400 records , a select takes more than 16 seconds. The map-reduce is running entirely on a different collection. Also we noticed node is unable to connect - resets the connection and on a new connection query is run which normally takes fraction of a second now takes nearly 16 seconds to comeback with a count of < 300 records. Conn5865 - Command Count takes 16509 ms while map reduce is running. Under normal load conditions < 100 milliseconds. , acquireWaitCount: { r: 3 }, timeAcquiringMicros: { r: 7055 }}, Collection: { acquireCount: { r: 11 } } } protocol:op_query 135ms } cursorid:116290011101 keyUpdates:0 writeConflicts:0 exception: operation exceeded time limit code:50 numYields:0 reslen:74 locks:{ Global: { acquireCount: { r: 2 }, acquireWaitCount: { r: 1 }, timeAcquiringMicros: { r: 19300914 }}, Database: { acquireCount: { r: 1 }}, oplog: { acquireCount: { r: 1 } } } protocol:op_command 19301ms ] } } planSummary: COUNT_SCAN { scan_status: 1.0 }keyUpdates:0 writeConflicts:0 numYields:1 reslen:62 locks:{ Global: { acquireCount: { r: 4 }, acquireWaitCount: { r: 1 }, timeAcquiringMicros: { r: 16503711 }}, Database: { acquireCount: { r: 2 }, acquireWaitCount: { r: 1 }, timeAcquiringMicros: { r: 5971 }}, Collection: { acquireCount: { r: 2 } } } protocol:op_query 16509ms var key = this._id; ; //printjson(values) , jsMode: true, sort: { _id: 1 }, readPreference: "primary" } planSummary: COUNT keyUpdates:0 writeConflicts:0 numYields:850 reslen:218 locks:{ Global: { acquireCount: { r: 382226, w: 216813, W: 54201 }}, Database: { acquireCount: { r: 54635, w: 216807, R: 971, W: 8 }, acquireWaitCount: { W: 2 }, timeAcquiringMicros: { W: 24771 }}, Collection: { acquireCount: { r: 54635, w: 108406 }}, Metadata: { acquireCount: { w: 108403 }}, oplog: { acquireCount: { w: 108403 }} } protocol:op_query 24225ms |
| Comments |
| Comment by Ramon Fernandez Marina [ 01/Apr/16 ] |
|
Closing this issue as per your latest comment ppeddada. |
| Comment by pavan [ 31/Mar/16 ] |
|
Looks like Map-Reduce by default locks the entire database as opposed to locking just the collections that its working on, using the 'nonAtomic' option seems to be addressing the issue reported here. This is not an issue anymore. |
| Comment by pavan [ 31/Mar/16 ] |
|
MongoTop output, clearly shows the only two operations running are map-reduce and the query. ns total read write 2016-03-31T14:58:36-07:00 |