A Guide to Analyzing MongoDB Performance Metrics with mongotop and mongostat

MongoDB performance problems often show up as slow pages, backed-up writes, or sudden connection spikes. mongotop and mongostat, installed with MongoDB Database Tools, give you a fast terminal view of what the server is doing right now.

This guide shows how to read those tools during common incidents, then connect the output to likely next checks such as indexes, query shape, connection pooling, and disk pressure.

Understanding mongotop

mongotop provides a real-time view of the read and write operations occurring on your MongoDB instances. It displays the time spent by each collection in read or write operations over a specified interval. This is particularly useful for identifying which collections are experiencing the most activity and could potentially be a source of performance degradation.

Key Metrics Provided by mongotop:

• ns: The namespace of the collection (database.collection).
• total: Time spent reading from and writing to the namespace during the sample interval.
• read: Time spent on read activity during the sample interval.
• write: Time spent on write activity during the sample interval.

How to Use mongotop:

You can run mongotop directly from your terminal, provided you have the MongoDB database tools installed and accessible in your PATH. By default, it updates every second. You can also specify an interval in seconds.

mongotop

To specify an update interval (e.g., every 5 seconds):

mongotop 5

To run mongotop against a MongoDB instance running on a different host and port:

mongotop --host <hostname> --port <port>

Interpreting mongotop Output:

• High write time on a specific collection: The collection is seeing heavy write activity. Check write volume, document growth, indexes touched by writes, and whether the workload should be sharded.
• High read time: Check query plans for that collection. Missing indexes, large result sets, and aggregation scans often show up here.
• Collections with consistently high total time: These are your hottest collections. Monitor their indexes, working set, and query patterns closely.

Understanding mongostat

mongostat provides a broader, real-time overview of the performance and resource utilization of a MongoDB instance. It collects and displays a variety of metrics about the server's state, including operations per second, network traffic, disk I/O, and memory usage.

Key Metrics Provided by mongostat:

• insert: Operations per second for inserts.
• query: Operations per second for queries.
• update: Operations per second for updates.
• delete: Operations per second for deletes.
• getmore: Operations per second for getmore operations (used for cursors).
• command: Operations per second for commands.
• dirty or dirty %: WiredTiger cache data modified in memory but not yet written to disk. The exact column name depends on MongoDB and tool versions.
• used or used %: WiredTiger cache usage. The exact column name depends on MongoDB and tool versions.
• conn: Current number of connections.
• networkIn: Network traffic received by the server (in bytes).
• networkOut: Network traffic sent by the server (in bytes).
• res: Resident memory size used by the MongoDB process (in MB).
• qr|qw: Number of queued read and write operations, when the column is available.
• ar|aw: Number of active read and write clients, when the column is available.

How to Use mongostat:

mongostat is also a command-line utility. Similar to mongotop, it updates periodically, with a default interval of 5 seconds. You can specify a different interval and connection details.

mongostat

To specify an update interval (e.g., every 2 seconds):

mongostat 2

To connect to a remote MongoDB instance:

mongostat --host <hostname> --port <port>

Interpreting mongostat Output:

• High insert, query, update, or delete rates: Indicates heavy operational load. Monitor these alongside other metrics to understand if the system is keeping up.
• High conn: A large number of connections can strain server resources. Investigate connection pooling in your application if this is unexpectedly high.
• High networkIn or networkOut: Suggests significant data transfer. This could be due to large queries, replication traffic, or large result sets being returned.
• High res: The MongoDB process is consuming a lot of RAM. Ensure your server has sufficient memory and check for inefficient queries or large datasets that might contribute to high memory usage.
• High qr|qw: Indicates that reads or writes are being queued, which usually points to resource contention or a workload the server cannot process quickly enough.
• High dirty or cache used values: If WiredTiger cache pressure stays high, your working set may not fit comfortably in memory, or disk writes may be falling behind.
• Slow queries with low operation rates: Use the profiler, slow query log, or explain() to check whether queries are scanning too many documents. Modern mongostat output does not reliably expose a single index-miss percentage for WiredTiger deployments.

Practical Use Cases and Troubleshooting Scenarios

Scenario 1: Slow Application Performance

1. Run mongostat: Observe qr, aw, insert, query, update, delete rates. If qr or aw are high, or if operation rates are high but don't seem to be processing quickly, it suggests a backlog.
2. Run mongotop: Identify which collections are experiencing the most read ms and write ms. A collection with high write activity might be slowing down other operations.
3. Check query plans: For the hot collections identified by mongotop, run explain("executionStats") on representative slow queries.
4. Analyze networkIn/networkOut in mongostat: If they are unusually high, look for large result sets, large aggregations, or replication traffic.

Scenario 2: High CPU or Memory Usage

1. Run mongostat: Monitor res (resident memory) and CPU usage (often observable via system tools like top or htop, but mongostat gives DB-specific perspective). High res might correlate with the wiredTiger cache (used %).
2. Examine mongotop: High read/write ms on specific collections can contribute to high CPU usage.
3. Look at mongostat's operation rates: If inserts/updates/deletes are extremely high, this naturally consumes CPU.
4. Investigate WiredTiger cache and disk metrics: If dirty cache stays high while application writes slow down, compare MongoDB output with host disk latency and I/O saturation.

Scenario 3: Replication Lag

While mongotop and mongostat don't directly measure replication lag, they are crucial for understanding the cause of lag.

1. Run mongostat on the primary: Look for high qr or aw, high write operation rates, or high CPU/memory usage. If the primary is overloaded, it cannot efficiently write to its oplog, leading to lag on secondaries.
2. Run mongostat on the secondary: Observe its read/write operations. If the secondary is slow to apply oplog entries, it might be due to insufficient resources on the secondary or inefficient queries/operations being applied.

Tips and Best Practices

• Run Tools Regularly: Don't wait for performance issues to arise. Monitor your MongoDB instances proactively.
• Establish Baselines: Understand what "normal" looks like for your deployment. This makes it easier to spot deviations.
• Combine with Other Tools: mongotop and mongostat are excellent for real-time snapshots. For historical analysis, consider using MongoDB's built-in performance monitoring (e.g., db.serverStatus(), db.stats()) or external tools like Prometheus with the MongoDB Exporter, or cloud provider monitoring services.
• Understand Your Working Set: Knowing the size of your active data set is crucial for memory management and understanding wiredTiger cache effectiveness.
• Focus on Query Plans: Use explain("executionStats") and the slow query log to confirm whether missing or inefficient indexes are causing scans.
• Consider Connection Pooling: High conn counts can often be mitigated by implementing proper connection pooling in your application layer.

Takeaway

Use mongostat to understand server-level pressure and mongotop to find the collections receiving the most read or write attention. When either tool points to a hot area, confirm the cause with query plans, slow query logs, host metrics, and application connection behavior before changing indexes or scaling the deployment.