Troubleshooting and Debugging MongoDB
Answer:
I would first check the MongoDB logs for errors or slow queries. Then, I'd use mongostat and mongotop to monitor real-time performance metrics and identify active operations or collections consuming resources. Finally, I'd analyze db.currentOp() to see ongoing operations.
How do you identify slow-running queries in MongoDB?
Answer:
I use the db.setProfilingLevel(1, { slowms: 100 }) command to enable database profiling, which logs queries exceeding a specified threshold. Alternatively, I can use db.system.profile.find() to query the profiler collection directly for slow operations. The explain() plan is also crucial for understanding query execution.
Answer:
I would use explain('executionStats') to analyze the query plan, identify missing indexes, or inefficient stages. Based on the explain output, I'd create appropriate indexes. If indexing isn't enough, I'd consider schema redesign or query restructuring.
How do you troubleshoot high CPU utilization on a MongoDB server?
Answer:
High CPU often indicates inefficient queries, missing indexes, or excessive write operations. I'd check mongostat for active operations, db.currentOp() for long-running processes, and the profiler for slow queries. OS-level tools like top or htop can also pinpoint the mongod process's CPU usage.
What are common causes of high memory usage in MongoDB, and how do you address them?
Answer:
High memory usage can be due to large working sets, inefficient queries pulling too much data into RAM, or unoptimized aggregation pipelines. I'd check db.serverStatus().wiredTiger.cache for cache utilization and ensure proper indexing to reduce data scanned. Scaling up RAM or sharding might be necessary.
Describe how you would debug a replica set that is not syncing correctly.
Answer:
I'd start by checking rs.status() on all members to identify the state and health of each node. Then, I'd examine the MongoDB logs on each member for replication-related errors, network issues, or oplog application failures. Network connectivity between members is also a common culprit.
What is the purpose of the MongoDB profiler, and how do you enable it?
Answer:
The MongoDB profiler captures detailed information about database operations, including query execution times, locks, and I/O. It helps identify slow queries and operations. You enable it using db.setProfilingLevel(level, { slowms: threshold }), where level can be 0 (off), 1 (slow operations), or 2 (all operations).
How do you handle a situation where a MongoDB instance runs out of disk space?
Answer:
First, I'd identify what's consuming space using db.stats() and db.collection.stats(). Then, I'd look for large log files or old backups to delete. If data growth is the issue, I'd consider adding more disk space, implementing sharding, or archiving old data to reduce the working set.
You suspect a deadlocked operation. How would you investigate this in MongoDB?
Answer:
MongoDB uses optimistic concurrency control, so true deadlocks are rare. However, long-running operations holding locks can block others. I'd use db.currentOp() to identify operations with waitingForLock status and see which operation is holding the lock. I might then terminate the blocking operation if necessary.
Answer:
Key metrics include opcounters (reads, writes, commands), connections (current, available), network (bytes in/out), memory (resident, virtual, mapped), wiredTiger.cache (dirty bytes, pages read/written), and locks (global, database, collection). These provide insights into workload and resource utilization.
