[SERVER-12615] Hitting Max Document size upon Map/Reduce? Created: 04/Feb/14 Updated: 11/Jul/16 Resolved: 19/Mar/14 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | MapReduce |
| Affects Version/s: | 2.5.5 |
| Fix Version/s: | 2.6.0-rc2 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Brad C. | Assignee: | Mathias Stearn |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
CentOS 6.5 x86_64 Sharded |
||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Participants: | |||||||||
| Description |
|
I'm running an incremental map reduce over a large data set in a sharded environment. The output is set to "reduce". This strategy works fine until the batch I'm running the MR on exceeds ~14Million documents. At which point the MR will fail with error code 10334 saying: "MR Parallel Processing failed. errmsg: 'Exception: BSONObj size 16951756 ... is invalid ..." I was under the impression that there are no size concerns when it comes to map/reduce. (Assuming of course your document size doesn't exceed 16MB. All of the documents I'm dealing with are ~400bytes). It doesn't fail immediately and I suspect it's the cumulative data from one shard or another that is exceeding this size. I wasn't aware that this was an issue with MR in sharded environments. Any ideas what's going on? |
| Comments |
| Comment by Githook User [ 19/Mar/14 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Author: {u'username': u'RedBeard0531', u'name': u'Mathias Stearn', u'email': u'mathias@10gen.com'}Message: The old calculation didn't consider the size of the numeric-string fieldnames (cherry picked from commit 3e0aa5769dd58c727726c3397f9678d7f767b7ff) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Githook User [ 19/Mar/14 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Author: {u'username': u'RedBeard0531', u'name': u'Mathias Stearn', u'email': u'mathias@10gen.com'}Message: The old calculation didn't consider the size of the numeric-string fieldnames | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Mathias Stearn [ 14/Mar/14 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Turns out that while | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Mathias Stearn [ 14/Mar/14 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Please try again with 2.6.0-rc2 once it is released. If this still occurs, please reopen. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Mathias Stearn [ 14/Mar/14 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
I think this is a side-effect of | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Brad C. [ 05/Feb/14 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Some additional info.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Brad C. [ 05/Feb/14 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Thanks for the reply and apologies that this info wasn't provided initially. It's somewhat sensitive in nature so here's a scrubbed version which should be consistent with what we're running.
For clarification, the line:
Is there to capture all fields in the original document without knowing what it might contain beforehand. Since this seemed to be the most likely culprit for some sort of recursion, I tried omitting this particular line and just explicitly emitting attributes from the document but the same error occurs. If it were recursing in some fashion I wouldn't expect it to work for 10 million documents and produce the expected output but not work for 15 million. It may also be worth noting a bug/peculiarity I've observed when viewing the status of the MR in db.currentOP() where "Emit progress" climbs into the millions of % complete.
It's suggested in your MR documentation that pre-sorting the data by the emit key may be beneficial. As you can see, that line is commented out because when it's active it's incredibly slow even though there is a compound index on a:1,b:1,c:1,d:1. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Mathias Stearn [ 04/Feb/14 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Could you include a set of steps to reproduce, including the exact command you are sending to trigger the mapReduce? Sometimes these errors can be caused by errors in the map or reduce functions that cause the output to be much larger than expected. |