The profiler helps find slow database queries so you can make your app faster.
Profiler for slow queries in MongoDB
db.setProfilingLevel(level, { slowms: milliseconds })
// To check current profiling level and slowms
db.getProfilingStatus()
// To see slow queries recorded
db.system.profile.find({ millis: { $gt: threshold } })level can be 0 (off), 1 (slow queries), or 2 (all queries).
slowms sets the threshold in milliseconds to consider a query slow.
db.setProfilingLevel(1, { slowms: 100 })
db.setProfilingLevel(0)db.getProfilingStatus()
db.system.profile.find({ millis: { $gt: 200 } }).sort({ millis: -1 })This example turns on profiling for queries slower than 50 ms, runs a query, then fetches slow queries from the profiler.
db.setProfilingLevel(1, { slowms: 50 }) // Run a sample slow query db.orders.find({ price: { $gt: 1000 } }).toArray() // Check slow queries recorded const slowQueries = db.system.profile.find({ millis: { $gt: 50 } }).sort({ millis: -1 }).toArray() slowQueries
Profiling can slow down your database, so use it only when needed.
Remember to turn off profiling (level 0) after you finish to avoid extra load.
The profiler stores data in the system.profile collection inside your database.
The profiler helps find slow queries by recording them.
Set profiling level and slowms threshold to control what is recorded.
Check system.profile collection to see slow queries and improve performance.
Practice
Solution
Step 1: Understand profiler's role
The profiler records queries that exceed a time threshold to help identify slow operations.Step 2: Identify what profiler does not do
It does not fix or delete queries automatically; it only logs them for review.Final Answer:
To record queries that take longer than a specified time to help optimize performance -> Option BQuick Check:
Profiler logs slow queries = To record queries that take longer than a specified time to help optimize performance [OK]
- Thinking profiler fixes queries automatically
- Confusing profiler with query caching
- Assuming profiler deletes slow queries
Solution
Step 1: Recall profiling levels
Level 1 logs slow queries exceeding the slowms threshold.Step 2: Check correct syntax
The correct syntax uses level and options object with slowms key, so db.setProfilingLevel(1, { slowms: 100 }) is valid.Final Answer:
db.setProfilingLevel(1, { slowms: 100 }) -> Option CQuick Check:
Level 1 + slowms option = db.setProfilingLevel(1, { slowms: 100 }) [OK]
- Using level 2 to log only slow queries (it logs all queries)
- Passing slowms as second argument without object
- Setting level 0 which disables profiling
db.system.profile.find({ millis: { $gt: 50 } })What does this query return?
Solution
Step 1: Understand the query filter
The filter { millis: { $gt: 50 } } selects documents where the millis field is greater than 50.Step 2: Interpret millis field meaning
Millis records query execution time in milliseconds, so this finds queries slower than 50ms.Final Answer:
All queries that took more than 50 milliseconds -> Option AQuick Check:
Filter $gt 50 means queries > 50ms = All queries that took more than 50 milliseconds [OK]
- Confusing $gt with $lt (greater than vs less than)
- Thinking it returns queries equal to 50ms
- Assuming it returns all queries
db.setProfilingLevel(1, { slowms: '100' }) but no slow queries are logged. What is the problem?Solution
Step 1: Check slowms parameter type
slowms expects a number, but '100' is a string, causing it to ignore the threshold.Step 2: Understand profiling behavior
Profiling level 1 logs slow queries, no restart needed, and default slowms is 100ms if not set.Final Answer:
The slowms value should be a number, not a string -> Option DQuick Check:
slowms must be numeric, not string = The slowms value should be a number, not a string [OK]
- Passing slowms as string instead of number
- Thinking profiling level 1 disables logging
- Believing MongoDB needs restart after setting profiler
Solution
Step 1: Sort queries by execution time descending
Sorting by millis: -1 orders queries from slowest to fastest.Step 2: Limit results to top 3
Using limit(3) returns only the first three documents after sorting.Final Answer:
db.system.profile.find().sort({ millis: -1 }).limit(3) -> Option AQuick Check:
Sort descending + limit 3 = db.system.profile.find().sort({ millis: -1 }).limit(3) [OK]
- Sorting millis ascending returns fastest queries
- Filtering millis less than 3 returns wrong data
- Not sorting before limiting results
Ready to prove it?
Pass the test and this pattern moves unknown
