[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: Text File Mongo.txt    
Issue Links:
Duplicate
duplicates SERVER-2942 MapViewOfFileEx failed during large i... Closed
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

Generated at Thu Feb 08 03:10:12 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.