Sign up ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

I've created web app that use mongodb, my mongo database currently has 4,05 GB , but every day it increase, next year it will probably have about 8 GB ,

I have python scripts that runs every 30 minutes , collect data from Clear Case system and store it in mongodb ,

problem is that server where is web app runned, often crashes and restarts, that cause data corruption in my mongo database, so my web app don't works good , when user type information that will run mongo query that will get corrupcted data.

I solve this problem with backups, every week I make backup and when I notice data corrupcion I replace my mongodb with backup, but this isn't good solution .

I tried repairDatabase , but I get error


"errmsg" : "exception: can't map file memory - mongo requires 64 bit build for larger    datasets",

"code" : 10084,

"ok" : 0


I'm newbie in mongodb, can someone tell me more about durability in MongoDB, and other limitations in mongoDB, e.g. How will size of mongo database affect to work on my web app , next year size will be at least 8 GB , maybe more ... Anyone has similar problems , how to solve it ....

share|improve this question

migrated from Apr 27 '14 at 17:43

This question came from our site for professional and enthusiast programmers.

what is problem, why get negative response... – user3578448 Apr 27 '14 at 15:04

2 Answers 2

up vote 1 down vote accepted

You seem to be using the 32bit version of mongoDB.

It's a miracle you actually got to 4.05GB, because the 32bit version only supports up to 2GB of data.

Any serious MongoDB deployment should be on a 64bit server with a 64bit operating system running a 64bit build of MongoDB. The 64bit version of MongoDB theoretically allows database of almost unlimited size. In reality, you are of course limited to the storage capactity of your server, but MongoDB can always scale horizontally by creating a shard of multiple servers.

Running 64bit will also allow the database to use journaling (the 32bit version also allows journaling in theory, but it's disabled by default because it further limits the amount of data you can store). With journaling enabled, MongoDB is far less likely to require a repair after a sudden crash.

share|improve this answer
thx,this help me a lot – blaz1988 Apr 28 '14 at 12:57
is there any cloud server as amazon that I can use only for mongodb ...? – blaz1988 Apr 28 '14 at 12:58
@user3578448 first google result for amazon mongodb – Philipp Apr 28 '14 at 13:05
ok thx I will read it now, currently I have available server with red hat enterprise 32 bit, that runs many web application, not just my. So you suggest me to take cloud server that will be only for mongoDB ... – blaz1988 Apr 28 '14 at 13:09
is better to have mongodb and web app on same server or seperatly ? – blaz1988 Apr 28 '14 at 13:13

Your problems here should be fairly self evident:

  • Server crashing continually: You are running your database on under-spec hardware. There is likely not enough memory available to support your usage. Another fair guess would be that MongoDB is not the only ( or at least main ) process running on this server, and that resources are being shared with something like the application itself and/or other server processes. Your database should have the resources it needs and should be on it's own server.

  • Error Reported on Repair: Which should be self explanatory. The specific message tells you that you are running a 32-bit build which cannot map the memory space that is required to repair the data in it's current size.

The best advice here is to commission a server instance that is suited to the actual usage that your application gets. The continual crashing should indicate that what you currently have is not up to the task.

At the very least, migrate the data somewhere at least temporarily where you can use a 64-bit build, invoke the repair and then make some hard decisions about your data.

If you are always accumulating new data then you might need to reconsider your retention of this if you are going to grow beyond the resources that are available to you. At any rate, everything you describe here points to trying to "shoe-horn" a larger solution into a small box, and this is the actual cause of all of the problems.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.