Maximizing MongoDB Performance on AWS

Editor's Notes

• #7: The reason for separating your deployment storage across 3 volumes is that database journal files and log files are sequential in nature, and as such, have different access patterns compared to data files. Separating data files from journal and/or log files, particularly with a write intensive workload, will provide an increase in performance by reducing I/O contention. Depending on your workload, and if you are experiencing high I/O wait times, you may be able to benefit from separate disks for your data files, journal, and log files.
• #8:  MongoDB can provide greater throughput for your deployment by using sharding to spread the load across instances, each holding a subset of your database. For example, if you distribute your data across three shards on independent instances, then your maximum throughput across all three will be 2400MiB/s.
• #9: We recommend using a redundant array of independent disks (RAID) to improve performance and durability of a MongoDB deployment. There are many levels of RAID, and each has its own advantages and disadvantages. The two key concepts underlying RAID are mirroring (RAID 1) where the same data is written to several disks and striping (RAID 0) where several disks are broken into stripes or bins with the data being copied across these. By using the proper RAID design, data durability and/or increased I/O performance is possible -- sometimes with one being sacrificed for the other. Fortunately, there is a RAID option that doesn’t sacrifice data reliability or increased I/O performance. RAID 10 (sometime called RAID 1+0) combines the features of RAID 1 and RAID 0. RAID 1 provides data reliability by mirroring data on secondary drives, whereas RAID 0 helps to increase I/O performance by striping data across drives. “In most cases, RAID 10 provides better throughput and latency than all other RAID levels, except RAID 0 (which wins in throughput). Thus, RAID 10 is the preferable RAID level for I/O-intensive applications such as database, email, and web servers, as well as for any other use requiring high disk performance.” As noted earlier, you also need to ensure that your total throughput of the combined RAIDed volumes does not exceed the maximum instance throughput. If there are more PIOPS than this maximum limit provisioned for your combined volumes the additional IOPS will be wasted.
• #11: If your instance type supports the Enhanced Networking feature, we strongly recommend that you enable it. There are unfortunately a few caveats as Amazon EC2 provides enhanced networking capabilities via single root I/O virtualization (SR-IOV) which is only available on C3, C4, D2, I2, M4, and R3 instances and only supported when you are using Amazon VPC (Virtual Private Cloud).
• #12: Amazon Virtual Private Cloud allows you to provision a private, isolated section in AWS where you can define your own IP address, subnets, route tables, and gateways. Using VPC private subnets when deploying MongoDB servers is recommended. By using Network Address Translation (NAT), your private subnet can access the Internet, but no one on the Internet can access your MongoDB servers. AWS provides a Managed NAT (Network Address Translation) Gateway service and we recommend using this. It enables the mapping of your private IP addresses in your VPC private subnet to a public address with traffic leaving AWS, and it then maps any public IP addresses back to your VPC subnet private addresses for traffic entering AWS. It is also possible to configure a site-to-site VPN connection to access your MongoDB deployment.
• #14: The working set is the portion of data and related indexes that your clients access most frequently. In cases where your data set is larger than memory, many random disk I/Os will happen which will affect performance as the necessary data is pulled from disk into memory.  Based on our experience helping to implement and support MongoDB deployments on AWS, we have found that the M4, I2, and R3 Amazon ECW instance types tend to be the most successful and widely used in customer deployments.
• #15: For example, if you are using the WiredTiger storage engine and running two mongod processes on the same instance, you would need to calculate the appropriate cache size needed for each mongod process by evaluating the portion of total RAM each process should use and then split the default cache size between each. If you improperly size the WiredTiger cache and the cache does not have enough space to load additional data, pages will be evicted from the cache to free up space, resulting in unnecessary I/O and performance degradation.