Atlas Cluster Sizing and Tier Selection

Cluster Auto-Scaling

Cluster tiers M10 and greater support Cluster Auto-Scaling. Cluster tier Auto-scaling is enabled by default when you create new clusters in the user interface. It is disabled by defaut if you create new clusters in the API. With auto-scaling enabled, Atlas automatically scales your cluster tier, storage capacity, or both in response to cluster usage. Auto-scaling allows your cluster to adapt to your current workload and reduce the need to make manual optimizations.

• Cluster storage scaling automatically increases your cluster storage capacity when 90% of disk capacity is used. This setting is enabled by default to help ensure that your cluster can always support sudden influxes of data. To opt out of cluster storage scaling, un-check the Storage Scaling checkbox in the Auto-scale section.

• Cluster tier scaling automatically scales your cluster tier up or down in response to various cluster metrics. To opt out of cluster tier auto-scaling, un-check the Cluster Tier Scaling checkbox in the Auto-scale section.

  To control how Atlas should auto-scale your cluster, you set:

  • The maximum cluster tier to which your cluster can automatically scale up. By default, this setting is set to the next cluster tier compared to your current cluster tier.
  • The minimum cluster tier to which your cluster can scale down. By default, this setting is set to the current cluster tier.

Memory

Memory refers to the total physical RAM available on each data bearing node of your Atlas cluster. For example, an M30 standard replica set is configured with 8 GB RAM on each of the 3 data bearing nodes.

Atlas uses the WiredTiger storage engine.

• By default, for M40 or larger clusters, WiredTiger dedicates 50% of physical RAM for the WiredTiger cache. The other 50% is reserved for in-memory operations such as sorts and calculations, the underlying operating system and other system services.
• By default, for M30 or smaller clusters, WiredTiger dedicates 25% of physical RAM for the WiredTiger cache.

To learn more about memory use, see WiredTiger and Memory Use.

MongoDB uses the WiredTiger cache to hold most recently used data and indexes. The working set is the sum of all the indexes plus the set of documents that are accessed frequently. If your working set fits in RAM, then MongoDB can serve queries from memory, which provides the fastest query response times.

To estimate the size of the working set, you can either perform a calculation using the information obtained from db.stats() for the total index space and assume a percentage of your data space will be accessed frequently, or you can estimate your memory requirements based on educated assumptions.

var totalIndexSize = 0;
var totalDataSize = 0;
var reservedDBs = ["admin","config","local"];
// Switch to admin database and get list of databases.
db = db.getSiblingDB("admin");
dbs = db.runCommand({ "listDatabases": 1 }).databases;
// Iterate through each database and get its stats.
dbs.forEach(function(database) {
   if (reservedDBs.includes(database.name))
       return;
   db = db.getSiblingDB(database.name);
       print("Obtaining stats for " + database.name);
   var stats = db.stats();
       totalIndexSize += (stats.indexSize / (1024*1024*1024)) ;
       totalDataSize += (stats.dataSize / (1024*1024*1024)) ;
});
print ("Total data size in GB: " + totalDataSize.toFixed(2));
print ("Total index size in GB: " + totalIndexSize.toFixed(2));

Obtaining stats for sample_airbnb
Obtaining stats for sample_geospatial
Obtaining stats for sample_mflix
Obtaining stats for sample_supplies
Obtaining stats for sample_training
Obtaining stats for sample_weatherdata
Total data size in GB: 0.32
Total index size in GB: 0.02

Network Traffic

All network traffic between cluster nodes and between clients consuming data from your Atlas cluster impact network bandwidth. For purposes of cluster sizing, consider the maximum traffic that any node on your cluster will bear and use this as the basis for selecting an adequate Atlas cluster tier.

Downstream data transfer rates from your cluster to client applications can be calculated as the sum of the total documents returned over a period of time. If you are reading only from the primary node, this is the only calculation you need to do. If your applications read from secondary nodes as well, you can divide this number by the number of nodes that can serve read operations.

You can find the average document size for a database with the db.stats() method. Multiply the average document size (avgObjSize) by the number of documents served per second to estimate your bandwidth requirements.

Atlas instances provide faster bandwidth speeds at the higher tiers. Instances which are backed by AWS provide up to 10 gigabits per second at the M30 level, while the M200 level provides up to 25 gigabits per second.