3

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 machine.

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.

  • I tried to frame this question as clearly as possible, is there a reason that question is unanswered? Or should I improve anything in the question? Please help!! I have 24 hours left to migrate.. – Sachin Kamkar Dec 18 '15 at 11:56
  • Any updates from your end? I'd assume you upgraded to MongoDB 3.2 and took adv of wiredtiger's compression and faster writes. You could use EC2 r3 for more ram processing. – Howard Lee May 9 '16 at 21:08
  • @HowardLee We haven't yet migrated to MongoDB 3.2(pending for a while now). And yes, we are using r3. large at the moment. – Sachin Kamkar May 12 '16 at 10:51
1

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.

  • Hi Nick, yes, we have hosted our Mongo on Ec2 and not RDS. I would love to know what you think on 1. Scalability choice for us (horizontal vs vertical) 2. The machine that should be chosen. – Sachin Kamkar Dec 16 '15 at 12:28
  • I don't have much experience scaling SQL - I run the smallest instance class in Multi-AZ with RDS. I just know that when using RDS, you can view your current IOPS, which would make it easier for you to decide how many you need. – nickdnk Dec 16 '15 at 12:29
  • As the DB we are talking about is Mongo, RDS does not come into the picture. Thanks for the help. Would like to know the monitoring tools that you use for Mysql.(Just out of interest) – Sachin Kamkar Dec 16 '15 at 12:32
  • RDS has built in tools, so that's all I use for MySQL. If you want to scale horizontally you need to create read replicas and divide your application into read and write handles, so that SELECTs can be offloaded. It is a lot easier to scale the server vertically to avoid all of this. – nickdnk Dec 16 '15 at 12:35
  • And yes, I understand that RDS is not an option - I just didn't remember if RDS supported MongoDB or not. – nickdnk Dec 16 '15 at 12:36
1

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. See: https://docs.mongodb.org/ecosystem/platforms/amazon-ec2/

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 : https://university.mongodb.com/courses/M202/about

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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