Finding Slow Queries with the Database Profiler
MongoDB's database profiler records detailed information about operations executed against a database, and can be enabled at three levels: 0 (off), 1 (log only operations slower than a configurable slowms threshold, default 100ms), or 2 (log every operation, useful only for short debugging sessions due to overhead). Profiler output is written to the system.profile capped collection and can be queried like any other collection, sorted by millis descending to surface the worst offenders first. In production, level 1 with a tuned slowms threshold is the standard approach, often paired with the slow query log that mongod writes to its log file regardless of profiler settings.
Cricket analogy: Setting the profiler to log operations slower than 100ms is like a coach reviewing only deliveries where the batter took over 2 seconds to react, filtering out routine balls to focus on genuinely slow reactions worth analyzing.
// Enable profiling for operations slower than 50ms
db.setProfilingLevel(1, { slowms: 50 });
// Find the 10 slowest recent operations
db.system.profile.find().sort({ millis: -1 }).limit(10);
// Check current profiling status
db.getProfilingStatus();$indexStats aggregation stage (db.collection.aggregate([{ $indexStats: {} }])) reports how often each index has actually been used since the last server restart — an excellent way to find unused indexes that are only adding write overhead with no read benefit.
Working Set and RAM
MongoDB performance depends heavily on how much of the 'working set' — the actively accessed data plus its indexes — fits in the WiredTiger cache, which defaults to roughly 50% of available RAM minus 1GB. When the working set exceeds available cache, MongoDB must repeatedly read pages from disk, and performance degrades sharply, especially on spinning disks or under-provisioned cloud volumes. Monitoring db.serverStatus().wiredTiger.cache for metrics like 'bytes currently in the cache' versus 'maximum bytes configured' reveals cache pressure, and a high 'pages read into cache' rate under steady load is a strong signal of memory-bound performance.
Cricket analogy: A working set that fits in RAM is like a captain keeping the current match's field placements in short-term memory, while data spilling to disk is like having to re-consult a printed manual for every single bowling change.
Schema Design Levers
Beyond indexing, schema shape directly affects performance: embedding related data that is always read together avoids costly $lookup joins, while referencing (storing an ObjectId and querying separately) is better for data that grows unbounded (like comments on a viral post) to avoid the 16MB document size limit and excessive document growth causing internal moves. Choosing appropriately sized batch operations (bulkWrite, insertMany) instead of many single-document round trips reduces network overhead significantly, and projecting only needed fields with find(filter, projection) reduces both network payload and, when combined with a covering index, disk I/O.
Cricket analogy: Embedding a player's career stats directly in their profile document is like a scorecard app storing batting averages inline for instant display, while referencing ball-by-ball commentary separately avoids one document growing unmanageably huge over a 20-year career.
MongoDB enforces a hard 16MB limit per document. Unbounded arrays (comments, events, logs appended indefinitely to a parent document) are a classic anti-pattern that eventually hits this limit and also causes expensive in-place document moves as they grow — model unbounded, growing data as a referenced child collection instead.
- The database profiler (levels 0/1/2) logs slow operations to system.profile for analysis, typically run at level 1 with a tuned slowms threshold in production.
- $indexStats reveals which indexes are actually used, helping identify and drop dead weight.
- Performance depends heavily on the working set fitting in the WiredTiger cache (roughly 50% of RAM minus 1GB by default).
- db.serverStatus().wiredTiger.cache metrics reveal cache pressure and disk-read-driven slowdowns.
- Embed data that is read together and bounded in size; reference data that grows unbounded.
- MongoDB enforces a hard 16MB per-document limit, making unbounded embedded arrays an anti-pattern.
- Use batch operations (bulkWrite, insertMany) and field projection to reduce network and I/O overhead.
Practice what you learned
1. What does profiler level 1 do by default?
2. What does the $indexStats aggregation stage report?
3. What is the approximate default size of the WiredTiger cache?
4. What is MongoDB's hard limit on a single document's size?
5. Which schema strategy is best for data that grows unbounded, like comments on a viral post?
Was this page helpful?
You May Also Like
Indexes in MongoDB
Learn how MongoDB indexes work internally, why they speed up queries, and how to create and manage the core index types.
Compound Indexes
Understand how MongoDB compound indexes combine multiple fields, the ESR rule for ordering keys, and how they support sorting and covered queries.
The Query Planner and explain()
Learn how MongoDB's query planner selects an execution plan and how to use explain() to diagnose slow queries.