[SERVER-6891] Mongo Db server terminates after several attemps of doing a sequence of operations 'repair database', 'drop capped collection', 'create capped collection' Created: 29/Aug/12  Updated: 11/Jul/16  Resolved: 29/Aug/12

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: 2.0.7
Fix Version/s: None

Type: Bug Priority: Minor - P4
Reporter: Pavel Surikov Assignee: Michael O'Brien
Resolution: Done Votes: 0
Labels: crash, storage, windows
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows 2003, Enterprise Edition, 32-bit


Attachments: Text File RepairDatabaseVerbose.txt    
Operating System: Windows
Participants:

 Description   

The problem appears when doing a sequence of operations 'repairDatabase', 'dropCollection', 'createCollection'. The collection created is a capped collection with the same name but with different size ranging from 100MB to 500MB.
After several attempts on chaning the size of a capped collection and doing a 'repairDatabase' before each attempt, MongoDb server terminates and the following error appears in the log file:

MapViewOfFileEx for ../data/$tmp_repairDatabase_0/sbm.1 failed with errno:8 Not enough storage is available to process this command. (file size is 536870912) in MemoryMappedFile::map, terminating

The following command is used to start the server:

mongod.exe --dbpath ..\data -vvvvvv --logpath ..\log\server.log

Here is the state of database files in data directory after crash:

$tmp_repairDatabase_0        (dir)
$tmp_repairDatabase_0\sbm.0  (16.0 MB (16,777,216 bytes))
$tmp_repairDatabase_0\sbm.1  (512 MB (536,870,912 bytes))
$tmp_repairDatabase_0\sbm.ns (16.0 MB (16,777,216 bytes))
_tmp        (dir, empty)
sbm         (dir, empty)
admin.0     (16.0 MB (16,777,216 bytes))
admin.ns    (1.00 MB (1,048,576 bytes))
mongod.lock (5 bytes (5 bytes))
sbm.0       (16.0 MB (16,777,216 bytes))
sbm.1       (512 MB (536,870,912 bytes))
sbm.2       (512 MB (536,870,912 bytes))
sbm.ns      (16.0 MB (16,777,216 bytes))



 Comments   
Comment by Eric Milkie [ 29/Aug/12 ]

Hi Pavel,
Thanks for your comments. Yes, I would expect the behavior to be different in Win2003 vs. 2008; you need to have more than just an amount of free virtual address space; you also need free continuous blocks of memory, and memory layout can be quite different between OS versions.

Comment by Pavel Surikov [ 29/Aug/12 ]

Hi Eric, I'm not sure if you've seen my response in comments. Thank's for
explanation it solves the problem, the issue can be closed.


Суриков Павел

Comment by Pavel Surikov [ 29/Aug/12 ]

Thanks Eric! I suspected that repair will need to use some additional storage and when I used the sizes of capped collections lower than < 240 MB I was not able to reproduce that problem. However I also could not reproduce it on Windows 2008 32-bit even with sizes up to 500MB. And this detail forced me to submit the bug, because it behaves differently on both 32-bit systems.
But I think this particular issue can be closed now.

Comment by Eric Milkie [ 29/Aug/12 ]

The "not enough storage" error means you are out of virtual address space. In 32-bit mode, you only have 4 GB of virtual address space. While a repair is running, it needs twice as much memory as a normal running state, and your 'sbm' database is already over 1 GB – it simply isn't possible in 32-bit mode to do what you're trying to do.

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