MongoDB Routine Inspection Commands Overview
MongoDB Routine Inspection Commands Overview
Table of Contents- MongoDB Routine Inspection Commands Overview - Monitoring System Operational Status - Checking Collection and Index Status - Replica Set Synchronization Status - Sharding State Monitoring - Balance Operation Status - System Performance Metrics - Identifying Slow Queries - Analyzing and Optimizing Slow Query Logs
Monitoring System Operational Status
> rs.secondaryOk() // Allow secondary reads; new versions use rs.secondaryOk()
> db.serverStatus() // Retrieve server operational statistics
> db.stats() // Get database-level information
> db.stats(1048576) // Return sizes in MB
> db.stats(1073741824) // Return sizes in GB
> db.collectionName.stats() // Get detailed stats for a specific collection
> db.collectionName.stats(1048576) // Return sizes in MB
> db.collectionName.stats(1073741824) // Return sizes in GB
> db.currentOp() // View currently executing operations
> rs.status()
> rs.printReplicationInfo()
> sh.status() // Requires mongos to execute
> sh.status({"verbose":1}) // Verbose output, may flood terminal
- Key elements in db.serverStatus():
...
...
// Connection count inspection
rsB:PRIMARY> db.serverStatus().connections
{ "current" : 54, "available" : 81866, "totalCreated" : 561, "active" : 2 }
...
...
// Asserts indicate server and client exceptions or warnings. High assert counts suggest system issues
"asserts" : {
"regular" : 0,
"warning" : 0,
"msg" : 0,
"user" : 27014,
"rollovers" : 0
},
...
...
// Opcounters reflect operation counts. Helps understand data access patterns
"opcounters" : {
"insert" : NumberLong(11660322),
"query" : NumberLong(80420411),
"update" : NumberLong(49059748),
"delete" : NumberLong(110001),
"getmore" : NumberLong(54813),
"command" : NumberLong(187889461)
},
- Access keys: db.serverStatus().key
mongos> Object.keys(db.serverStatus()) // List available keys
[
"host",
"version",
"process",
"pid",
"uptime",
"uptimeMillis",
"uptimeEstimate",
"localTime",
"asserts",
"connections",
"extra_info",
"logicalSessionRecordCache",
"network",
"opcounters",
"sharding",
"shardingStatistics",
"tcmalloc",
"trafficRecording",
"transactions",
"transportSecurity",
"mem",
"metrics",
"ok",
"operationTime",
"$clusterTime"
]
Checking Collection and Index Status
> db.collectionName.find({filter}).count() // Count documents matching filter
> db.collectionName.getIndexes() // Display existing indexes, formatted neatly
Replica Set Synchronization Status
> use local
> db.getReplicationInfo()
> rs.printReplicationInfo()
- Default oplog size is 990MB. If retention is less than 12 hours, increase it using:
Step #1: > db.adminCommand({replSetResizeOplog: 1, size: 2048})
Step #2: Update mongod.conf accordingly
$ vi ../conf/mongod.conf
replication:
oplogSizeMB: 2048
Sharding State Monitoring
> use databaseName
> sh.status() // View sharding configuration
> db.database.getShardDistribution() // Check distribution across shards
Balance Operation Status
> sh.getBalancerState() // Check if balancer is enabled
> sh.isBalancerRunning() // Check if balance process is active
> sh.getBalancerWindow() // Show balance window settings
- Recommended to schedule balance during off-peak hours to avoid performance impact. Example: 23:00–04:00
- Avoid running balance during backup windows to prevent inconsistencies
> db.settings.update({ _id :"balancer" }, { $set : { activeWindow : { start :"23:00", stop :"04:00" } } }, true )
System Performance Metrics
MongoDB includes built-in tools for real-time performance monitoring: mongostat and mongotop.
- mongostat offers real-time insights into instance activity, including key metrics. Example output refreshes every 10 seconds.
- Pay attention to dirty and used percentages. High values (>20% dirty or >95% used) signal performance issues.
> mongostat --port port --authenticationDatabase admin -u user -p password 10 --discover
host insert query update delete getmore command dirty used flushes mapped vsize res faults qrw arw net_in net_out conn set repl time
localhost:port 86 571 93 *0 2 42|0 0 0B 1.08G 437M 0 0|0 0|0 406k 38.5m 332 RTR Dec 8 11:21:08.175
db01:port 34 454 1063 *0 204 512|0 4.9% 80.0% 0 23.7G 17.0G n/a 0|0 1|0 1.49m 57.9m 70 rsA PRI Dec 8 11:20:58.207
db01:port *1 *0 *350 *0 9 6|0 1.7% 79.9% 1 25.1G 19.2G n/a 0|0 1|0 6.85k 55.5k 79 rsC SEC Dec 8 11:20:58.333
db02:port *36 *0 *472 *0 196 236|0 5.0% 79.9% 0 24.6G 16.7G n/a 0|0 1|0 292k 607k 51 rsA SEC Dec 8 11:20:58.228
db02:port 1 1387 1028 *0 243 317|0 1.1% 79.9% 1 28.6G 23.0G n/a 0|0 1|0 2.25m 60.0m 125 rsC PRI Dec 8 11:20:58.354
db03:port *35 *0 *468 *0 6 5|0 4.4% 79.4% 0 24.6G 18.9G n/a 0|0 1|0 4.90k 53.6k 51 rsA SEC Dec 8 11:20:58.249
db03:port *1 *0 *346 *0 2 4|0 5.0% 79.7% 0 25.9G 18.1G n/a 0|0 1|0 1.93k 52.0k 70 rsC SEC Dec 8 11:20:58.373
db04:port *254 *0 *336 *0 1 4|0 5.1% 79.3% 0 23.5G 17.2G n/a 0|0 1|0 1.53k 42.7k 44 rsB SEC Dec 8 11:20:58.271
db05:port 254 382 1019 *0 111 287|0 4.8% 80.0% 0 21.5G 17.1G n/a 0|0 1|0 1.52m 52.6m 63 rsB PRI Dec 8 11:20:58.293
db06:port *254 *0 *330 *0 107 138|0 5.0% 79.9% 0 24.1G 16.2G n/a 0|0 1|0 167k 878k 45 rsB SEC Dec 8 11:20:58.315
Column Descriptions:
column1 Description
insert Documents inserted per second. Secondary nodes show * prefix
query Queries executed per second. Secondary nodes show * prefix
update Updates applied per second. Secondary nodes show * prefix
delete Deletes performed per second. Secondary nodes show * prefix
getmore Getmore operations for cursors. Less significant metric
command Commands executed per second. Secondary nodes show two values, local
dirty Dirtiness percentage in WiredTiger cache
used Cache usage percentage in WiredTiger engine. Ideal is similar dirty/used ratios. Used >> Dirty suggests memory pressure
flushes Flush operations per second. Typically 0 or 1. Frequent flushes need investigation
mapped/vsize/res Similar to top command. mapped/vsize stable, res grows over time. Sudden drops may indicate memory issues
faults Number of page faults. Non-zero often means memory shortage
qrw Client queue lengths for reads
arw Active client connections for reads
netIn/netOut Network traffic in/out. MongoDB rarely causes bandwidth issues
conn Open connection count. Each connection spawns a thread. Avoid high numbers
- mongotop monitors read/write operations per collection in real-time. Connects directly to mongod instances, not mongos
> mongotop --port port --authenticationDatabase admin -u user -p password 10
2023-12-08T14:25:22.947+0800 connected to: mongodb://localhost:port/
ns total read write 2023-12-08T14:25:32+08:00
db.collection 999ms 0ms 999ms
db.collection 36ms 0ms 36ms
local.oplog.rs 31ms 31ms 0ms
db.collection 31ms 0ms 31ms
db.collection 15ms 0ms 15ms
db.collection 10ms 0ms 10ms
db.collection 6ms 0ms 6ms
db.collection 2ms 0ms 2ms
db.collection 1ms 1ms 0ms
db.collection 1ms 1ms 0ms
Identifying Slow Queries
Recommendation: Temporarily enable profiling in production environments to gather data, then disable to minimize performance overhead.
> use admin
> db.getProfilingLevel() // Check current profiling level
> db.getProfilingStatus()
0: Disabled, no data collected
1: Collect slow queries, default threshold 100ms
2: Collect all operations
- Temporarily enable slow query logging
> db.setProfilingLevel(1,2000) // Enable slow query log at 2000ms threshold
> db.setProfilingLevel(0) // Disable profiling
> db.system.profile.find()
- Permanent config file modification
...
...
profile = 1
slowms = 2000
Analyzing and Optimizing Slow Query Logs
By default, MongoDB logs queries exceeding 100ms to mongod.log. Use this file for analysis.
Example #1: Find full table scans, excluding oplog and getMore
$ tail mongod.log -n 1000000 | grep ms | grep COLLSCAN | grep -v "getMore" | grep -v "oplog.rs"
Example #2: Capture all slow queries, excluding oplog and getMore
$ tail mongod.log -n 1000000 | grep ms | grep op_msg | grep -v "getMore" | grep -v "oplog.rs"
- Ensure nReturned, totalKeysExamined, and totalDocsExamined are consistent
- If totalKeysExamined >= totalDocsExamined > nReturned, optimization needed
- Index order matters: equality filters first, then range conditions
mongos> use databaseName
mongos> db.database.find({ "geometry" : { "$nearSphere" : { ...... }}).explain("executionStats")
......
"executionStats" : {
"nReturned" : 1, // Docs returned
"executionTimeMillis" : 1, // Execution time
"totalKeysExamined" : 12, // Keys scanned via index
"totalDocsExamined" : 2, // Documents scanned
"executionStages" : {
"stage" : "SINGLE_SHARD", // See stage list below
Stage Description
COLLSCAN Full collection scan
IXSCAN Index scan
FETCH Retrieve document by index
SHARD_MERGE Merge results from shards
SORT In-memory sort
SORT_MERGE In-memory sort and merge
LIMIT Limit number of returned docs
SKIP Skip documents
IDHACK Query by _id
SHARDING_FILTER Sharding filter
COUNT Count operation without index
COUNTSCAN Count with index
COUNT_SCAN Count with index
SUBPLAN $or without index
TEXT Full-text search
