Deciding EC2 Instance type & Volume IOPS for Mongo DB

Posted on

Question :

We have 500GB data in our Mongo(v2.6.3) including the indexes.

We currently run this on AWS m3.large(8GB RAM) instance. Yes, Single

Our MongoDB Cloud Manager shows these stats:

Opcounters – 1.5k
Background Flush Average – 5s
Non mapped Virtual Memory – 2GB
Lock Percentage – 15%
BTree – 6k
Connections – 2k
Queues – 100
Record Stats – 200
Page Faults – 1k

Our Mongo has become slower over the last few months as the Data is growing rapidly at the rate of 40GB per month.

We are sure this is the time to scale it up. We had difficult time deciding whether to scale it horizontally or vertically. What we decided then was that let’s scale vertically now. And six months down the line, as we will have more bandwidth in terms of people(currently we are a very small team), we will scale it Horizontally. We would love to have your views on this decision.

And moreover, the biggest confusion that we have is over choosing hardware.The options we have are:

AWS Ec2 r3.large - 2 CPU Cores - 15GB RAM
AWS Ec2 r3.xlarge - 4 CPU Cores - 30GB RAM

And we will be taking 1.5TB Volume but still confused with the number of IOPS that we need to reserve.

Hoping to get your views & valuable suggestions.

Answer :

You should be able to view your current IOPS on the monitoring page of AWS – at least you can for RDS instances.

If this is EC2 and not RDS (RDS is backed by EC2 instances) you probably need to enable enhanced monitoring for those instances.

On AWS you can very easily change the type of your instance. So, for safety you can start with a more powerful type, and downgrade it if you see it’s really not using any resources.

On AWS, when selecting an instance, you can find Disk Read/Write Operations on the monitoring tab.

Horizontal scaling is needed at a certain moment. A suggestion to start with, is 2 shards, with each a primary and a secondary instance in different availability zones. To complete the voting of you’re replicas, have a small type instance with an arbiter for each replica set.

  • shardA_repl1
  • shardA_repl2
  • shardB_repl1
  • shardB_repl2
  • arbiterA_arbiterB

In such a setup, the resources will be distributed also. So, whatever you calculated, it will be spread over the different servers.

Write to primaries, reading : secondary_prefered.

There are many optimizations that can be made like placing logfiles and journals on different disks and do some linux finetuning.

But also, review your amount of data, indexes and queries. Is all data needed? Are indexes created correctly? Can some queries be optimized?

Certainly, take your time for testing your setup. Create correct shard-keys because you can’t change that later. Try shutting down one of the instances, and everything should keep on running. Read about all options to optimize to use as small instances as possible.

A great source of practical information :

Leave a Reply

Your email address will not be published. Required fields are marked *