MongoDB Database Profiler

Your MongoDB cluster is humming along in production when a user reports that a critical endpoint is crawling. You check CPU, memory, and disk — all fine. The database is the bottleneck, but you have no idea which query is the culprit. The MongoDB database profiler is the built-in tool that records query execution details, including response times, so you can pinpoint slow operations and fix them before they become outages. This lesson shows you exactly how to monitor MongoDB performance with the database profiler — from enabling it to reading the output and acting on what you find.

The problem this lesson solves

Debugging performance issues in MongoDB without profiling is like searching for a black cat in a dark room. You might guess, but you'll waste time and risk making things worse. Common pain points include:

• Slow queries that degrade user experience but only appear under load.
• Inefficient indexes that aren't used, causing full collection scans.
• Memory pressure from operations that fetch too many documents.
• No visibility into which operations are slow, when, and why.

Without the profiler, you're flying blind. The profiler gives you a system.profile collection that records operation metadata like millis (execution time), nreturned (documents returned), and ns (namespace). With this data, you can move from guessing to evidence-based optimization.

Core concept / mental model

Think of the database profiler as MongoDB's built-in performance recorder — like a flight data recorder for your database. It doesn't fix problems; it tells you what happened, when, and how long it took. When enabled, MongoDB writes profiler records for operations that match your threshold into a capped collection named system.profile inside the database.

Profiling levels:

The profiler can be scoped at three levels: instance (via mongod config), database, or per-operation using db.setProfilingLevel(). The database-level setting is the most common for targeted monitoring.

Key definitions: - Profiling level: 0, 1, or 2 as above. - Slowms: the threshold in milliseconds for level 1. - system.profile: the capped collection storing profiler records (default 1MB). - Operation types: query, insert, update, remove, command.

In this mental model, your job is to enable the recorder, read the tape, and optimize the operations that stand out.

How it works step by step

1. Enable profiling on the target database. javascript db.setProfilingLevel(1, { slowms: 200 }) This records operations slower than 200ms. Level 2 records everything — use sparingly in production.

2. Verify the level using db.getProfilingStatus().

3. Run your application or workload for a period to capture real operations.

4. Query the system.profile collection — it's a normal capped collection, so you can query it like any other.

5. Analyze results: look for slow millis, high nreturned, large docsExamined, and missing indexes.

6. Optimize by adding indexes, adjusting query patterns, or rewriting operations.

7. Adjust profiling — raise slowms or disable profiling when not needed to reduce overhead (profiling itself adds a small cost).

Hands-on walkthrough

Let's apply this to a real scenario. Assume we have a users collection with 1 million documents and a query that's timing out.

1. Enable profiling and check status

// Connect to your database (e.g., 'appdb')
use appdb

db.setProfilingLevel(1, { slowms: 100 })

db.getProfilingStatus()
// Expected output: { was: 1, slowms: 100, sampleRate: 1 }

2. Run a slow query

// Simulate a slow query on an unindexed field
const start = new Date()
db.users.find({ email: "alice@example.com" }).toArray()
const elapsed = new Date() - start
print(`Query took ${elapsed} ms`)
// Output: Query took 175 ms (or similar)

3. Read the profiler record

db.system.profile.find(
  { ns: "appdb.users", op: "query" },
  { ns: 1, millis: 1, nreturned: 1, docsExamined: 1, ts: 1 }
).sort({ millis: -1 }).limit(5).toArray()

Output (simplified):

[
  {
    _id: ...,
    ns: "appdb.users",
    millis: 175,
    nreturned: 1,
    docsExamined: 1000000,
    ts: ISODate("2025-05-06T10:00:00Z")
  }
]

The docsExamined is a million — a full collection scan. nreturned is 1. That's the smoking gun.

4. Fix with an index and re-check

// Create an index on email
use appdb
db.users.createIndex({ email: 1 })

// Re-run the same query
const start = new Date()
db.users.find({ email: "alice@example.com" }).toArray()
const elapsed = new Date() - start
print(`Query took ${elapsed} ms`)

// Query the profiler again to confirm improvement
// Expect millis to drop drastically, docsExamined to be 1

After the index, the query should return in a few milliseconds with docsExamined: 1.

5. Keep only valuable profiler data

// Clear old profile entries (as needed – you may want to keep recent ones)
db.system.profile.drop()
// Re-create the collection as capped? Dropping and re-running setProfilingLevel will recreate it.

Pro tip: Instead of dropping the whole collection, use db.system.profile.find().sort({$natural:-1}).limit(100) to inspect recent records and archive older ones manually.

Compare options / when to choose what

Choose the database profiler when you need to see exactly what ran, how long it took, and how many documents were scanned — especially on self-managed MongoDB. For continuous monitoring in production, consider a real-time tool like mongostat combined with periodic profiler dumps.

Troubleshooting & edge cases

• Profiler not recording anything: Check the profiling level and slowms. Level 0 disables it. Make sure you're connected to the right database — use <db> matters.

• system.profile doesn't exist: It's created automatically when you enable profiling. If you drop it, you must call setProfilingLevel again to recreate it as capped.

• Profiler overhead too high: Level 2 in production can slow things down. Use level 1 with a reasonable slowms (e.g., 100–200 ms), or use sampleRate (as of MongoDB 4.2) to capture only a percentage of slow operations.

• Capped collection fills up: The default size is 1 MB; once full, oldest entries are overwritten. If you need more history, change the size before enabling profiling: drop system.profile, then db.createCollection( "system.profile", { capped: true, size: 10485760 } ) (10 MB).

• Cannot drop system.profile while profiling is on: Disable profiling first (db.setProfilingLevel(0)), then drop or resize.

• Profiler shows docsExamined huge but millis low: Indexes help, but you might be scanning too many documents — review your query filter for selectivity.

What you learned & what's next

You've learned how to monitor MongoDB performance with the database profiler — enabling levels, setting slowms, querying system.profile, and interpreting key fields like millis, docsExamined, and nreturned. You can now identify slow queries, add indexes, and verify improvements. This is a core skill for any MongoDB administrator or developer. Next, you'll learn how to use the profiler's findings to design effective indexes — the step after identification is optimization.