I am new to Mongodb and EC2. If I use following single MongoDb server :

High-Memory Extra Large Instance 17.1 GiB memory, 6.5 ECU (2 virtual cores with 3.25 EC2 Compute Units each), 420 GB of local instance storage, 64-bit platform

As a layman, if we quantify I/O, data in MB/sec. How much I/O transactions mongodb server can handle easily, without being burnt out.

Consider default settings of EC2 server with Ubuntu and MongoDb version available in AWS marketplace.

closed as not constructive by EEAA, Ward, John Gardeniers, Brent Pabst, mdpc Dec 11 '12 at 17:30

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.


With AWS.. you are better off sharding your data and scaling horizontally with mongo. If you are starting off that seems like big time overkill to me. Plus with mongo you want to replicate the database. So you'd need at least another server with the same specs.


In terms of IO, it has little to do with the instance size except for the bandwidth available to you. To explain, when you are using EC2/AWS that means you will be using EBS for storage, and so using the network to persist your data. As such the recommendation is to use RAID 10 across multiple volumes to allow you to stripe (performance), mirror (redundancy) and fail out a bad volume (otherwise your array is as slow as whatever the slowest disk is) if one of the EBS volumes has a bad day (it happens, trust me).

Per this whitepaper (which will be updated with new info soon), an EBS volume can provide

approximately 100 IOPS, and single instances with arrays of 10 or more attached EBS disks can often reach 1,000 IOPS sustained

If you use a provisioned IOPS instance then that all changes, of course, and it also means that you get a dedicated network interface for IO, removing any contention with your normal traffic on the host.

The final remaining option are the SSD based instances, which far outstrip even the provisioned IOPs capabilities, but there is quite a price difference to go along with them.

Generally with MongoDB you will end up sizing based on RAM (keeping your working set in RAM is usually considered paramount, if possible), but if you can't and you need to hit disk regularly, then the amount you can squeeze out of EBS will be important.

I recently presented an overview of all this, with an AWS focus at the recent Sydney/Melbourne MongoDB events. You can find the slides here:



This does depends on the size of the DB you are running.

If you are running a small mongoDB, then pretty soon most of the queries will be cached into memory, and your mongoDB won't be hitting disk anymore.

If it's a bigger DB and money is not a big problem for your, then I will suggest that you should go for High I/O instances, which have SSD fitted in them, and the best fit for running a mongoDB server.

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