I've had no problems with my Mongo set up for a couple of years until it shutdown unexpectedly yesterday. I found no error in the logs from around the time it stopped.

It seems like a neat coincidence that the size of the database is a fraction under 2GB. 1.953125GB to be exact.

Could this be a reason?

Additional info:

I'm running Mongo v2.1 on 64bit CentOS 5.5. The /data/db directory is on an ext3 partition.

The data file sizes look like this:

 64M  db.0
128M  db.1
256M  db.2
512M  db.3
1.0G  db.4
 16M  db.ns 
  • Does your filesystem support larger than 2GB files?
    – forcefsck
    Commented Apr 2, 2014 at 20:55
  • the data dir for mongo is on ext3. Does that support >2GB?
    – Tim
    Commented Apr 2, 2014 at 22:36
  • @Tim - mongodb has a max file size of 2GB for that reason (some FS/OS not supporting it) - it pre-allocates multiple files of 2GB (max, starts smaller) when databases exceed that size (see your data directory for database.0, database.1 etc.)
    – Adam C
    Commented Apr 3, 2014 at 8:40
  • Just to confirm: you're talking about each file size that the DB is split into, not the total DB size? I notice that each new file preallocation size doubles. db.0 64M, db.1 128M, db.2 256M and so on.
    – Tim
    Commented Apr 3, 2014 at 9:54
  • Can you post your mongod log (given it does not contain sensitive information)? There may be clues as to why this would happen even if nothing is printed at the time of the shutdown. Also have you checked your system logs for anything unusual? Commented Apr 3, 2014 at 14:17

2 Answers 2


You are using an unstable mongodb release - odd release numbers are for developmental testing and definitely not for production use. http://docs.mongodb.org/manual/release-notes/#release-version-numbers

Don't know if you've tried restarting but I'd also consider going to a stable production release (2.2/2.4 - 2.6 is brand new as a prod release) and try that.

  • Thanks. I didn't know about the odd-number business. valuable info.
    – Tim
    Commented Apr 11, 2014 at 9:44
  • After accepting this answer I upgraded to the 2.6, but the crash happened again today. Any other ideas? could this be due to large files on ext3?
    – Tim
    Commented Apr 19, 2014 at 20:44
  • How long did it run till it failed again? Anything in the log files? Did the process just end? Do you have at least 2GB free on your file system? (that is the size of the next extent it will try to allocated). MongoDB is definitely recommended to be on ext4 but I'm not aware of anything that would cause it to crash on ext3. I'd say it's worth creating an ext4 filesystem with plenty of free space, copy the files over and see if that works. Commented Apr 19, 2014 at 21:20
  • It ran for over 24 hours, but crashes seem fairly arbitrary and again the logs don't show anything interesting. In fact nothing in logs at all at time of last crash.
    – Tim
    Commented Apr 20, 2014 at 13:30
  • I have 3.2GB available. I guess I'll expand that and look at full upgrade to ext4. I'd still love to know the actual cause of crash though. I learn nothing from it otherwise.
    – Tim
    Commented Apr 20, 2014 at 13:30

Are you running a 32-bit machine? Mongo on 32-bit is limited to 2GB on a node unless you run multiple mongod processes and do some kind of partitioning. This is because Mongo uses memory-mapped files for I/O.

  • It's a 64 bit CentOS 5.5 box. Is it possible Mongo was compiled wrongly and has the 2GB limit?
    – Tim
    Commented Apr 2, 2014 at 20:48
  • Try doing file /path/to/mongod, it should tell you if it is a 64-bit executable.
    – phoebus
    Commented Apr 2, 2014 at 21:03
  • /usr/bin/mongod: ELF 64-bit LSB executable, AMD x86-64 ... Thanks for the tip though. I guess it's something else
    – Tim
    Commented Apr 2, 2014 at 22:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .