[SERVER-5901] Assertion failure p db\mongommf.cpp 198 - MapViewOfFileEx failed F:/data/xq.2 errno:487 Attempt to access invalid address Created: 22/May/12 Updated: 15/Aug/12 Resolved: 23/May/12 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Code |
| Affects Version/s: | 1.8.1 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | John Woakes | Assignee: | Tad Marshall |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | Windows, crash | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Single database running in MS Windows Azure |
||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Operating System: | Windows | ||||||||
| Participants: | |||||||||
| Description |
|
The mongod.exe terminated and Azure restarted the database which began recovering. The database eventually recovered. This happened in our production database twice in the last 48 hours. See attached logs for details. We need to know what is causing this and how to prevent it happening again. |
| Comments |
| Comment by John Woakes [ 24/May/12 ] |
|
Thanks again Tad. We don't do huge across the board updates so hopefully will be ok till 2.2 |
| Comment by Tad Marshall [ 23/May/12 ] |
|
Hi John, Version 2.1.0 will behave like version 2.0.x regarding the remapping of the journaling copy of the database, so it will not have the problem you reported here. Version 2.1.1 will behave like the 1.8.x versions and is subject to this problem. A current nightly build (labeled "2.1.2-pre-") should not have either problem ... no MapViewOfFileEx failures and no excessive memory consumption. The excessive memory consumption problem is being tracked in https://jira.mongodb.org/browse/SERVER-5663 . How much this affects you is determined by the kinds of updates you do to your databases. If small sections of the database are updated but the bulk is not changed, you may never have any problems. If every document in a 4 GB database is changed, this could consume 4 GB of page file space. The only real "workaround" is to turn off journaling, which is not safe unless you have a very solid system of up-to-date replicas and are willing to do a full resync in case of failure. Tad |
| Comment by John Woakes [ 23/May/12 ] |
|
Thanks Tad, We are now using 2.1.0 and will monitor memory usage. Does this version have the good or bad fix? We will use the 2.2 when it comes out. John. |
| Comment by Tad Marshall [ 23/May/12 ] |
|
Hi John, This is caused by mongod.exe trying to remap a copy of the database that is used for journaling and being unable to complete the remap because another thread allocated memory in the area needed by the memory-mapped file copy while the remap was being done. It is fixed in version 2.0, but in a way that caused other problems, specifically an ongoing increase in memory usage. It is fixed again, without the increase in memory usage, in the next version of MongoDB, version 2.2. You could try version 2.0.5 and see if the increased memory usage is a problem for you or wait for version 2.2 which will have a better fix. The Jira ticket we are using to track this issue is https://jira.mongodb.org/browse/SERVER-2942. Tad |