Performance

Monitoring your deployment

Databases for MongoDB deployments offer an integration with the IBM Cloud® Monitoring service for basic monitoring of resource usage on your deployment. Many of the available metrics, like disk usage and IOPS, are presented to help you configure autoscaling on your deployment. Observing trends in your usage and configuring the autoscaling to respond to them can help alleviate performance problems before your databases become unstable due to resource exhaustion.

Disk Usage

If you are concerned about how much space MongoDB is using to store your data, you can run some native MongoDB data storage diagnostics to find the sizes of things like databases, collections, and indexes. If the approximate size of your data set is known and fixed, you can manually scale your disk to accommodate your data. If your data set grows at predictable rate over time, you can configure autoscaling to increase disk size when your disk usage hits a certain threshold.

Disk I/O

The number of Input-Output Operations per second (IOPS) on Databases for MongoDB deployments is limited by the type of storage volume. Storage volumes for Databases for MongoDB deployments are Block Storage Endurance Volumes in the 10 IOPS per GB tier. Hitting I/O utilization limits can cause your databases to respond slowly or appear unresponsive. Things like unoptimized queries, index building, and creating new indexes can cause spikes in IOPS, but it's also possible that normal work loads for your applications can exceed the available IOPS for your deployment.

You can increase the number IOPS available to your deployment by increasing disk space. You can also configure autoscaling to increase disk size automatically if your deployment's I/O utilization hits a certain saturation point for an extended period of time.

For more information, see the MongoDB documentation.

WiredTiger Cache and Memory

Databases for MongoDB uses the WiredTiger storage engine, which uses both the file system memory cache and an internal memory cache. MongoDB is most performant when it serves your data from its internal cache, a little less performant when the data is in the file system cache, and least performant when it has to grab your data from disk.

The default size of the internal cache is 50% of (total RAM - 1 GB) or 256 MB, whichever is larger. For example, the minimum memory size of a Databases for MongoDB deployment is 1024 MB per data member, so the internal cache is 512 MB (because (3072 MB / 2) - 1 GB = 512.

The internal/file system cache ratio is not user-configurable on your deployment, but you can scale the total amount of memory to adjust the internal cache to make your database more performant. For example, if you scale the memory to 4096 MB per member the internal cache size becomes 5120 MB. (12288 MB / 2) - 1 GB = 5120 MB.

Another way to use autoscaling is to set memory to scale when disk I/O utilization hits a certain threshold. Increasing memory decreases the amount that MongoDB reads or writes to disk, so additional memory might alleviate pressure on disk I/O by supporting more caching.

More information about the WiredTiger cache is in the MongoDB documentation.

Query Performance

The MongoDB documentation has multiple resources on query performance, including a how-to on analyzing query performance. Once you have a general idea on how your queries perform, they also have tips on optimizing your queries.

As a more advanced topic, you can learn how MongoDB manages query plans.

Other MongoDB Monitoring Tools

You can also take advantage of some of the native MongoDB monitoring functions. For example, you can use both mongotop and mongostat.

mongotop 30 --username admin --password $PASSWORD --ssl --sslCAFile $CERTFILE --authenticationDatabase admin --host host1.databases.appdomain.cloud:31712, host2.databases.appdomain.cloud:31712

mongostat -n 20 1 --username admin --password $PASSWORD --ssl --sslCAFile $CERTFILE --authenticationDatabase admin --host host1.databases.appdomain.cloud:31712,host2.databases.appdomain.cloud:31712 --json

Run any of the documented commands that report on the status of your MongoDB database.

Many of the MongoDB utilities and commands need the Cluster Monitor role to execute. It is not part of the admin default role set. Grant the Cluster Monitor role to the admin user on your deployment.

For more information, see the Best Practices blog post.