MongoDB Memory Usage Too High? Where to Start Looking

01 · Sanity Check First

High memory usage is often the design working as intended

MongoDB's storage engine, WiredTiger, deliberately carves out a large chunk of memory for its own cache — roughly half of (system RAM − 1GB) by default — to hold hot data, indexes, and in-flight operations. That's not a leak, it's the design: idle memory is wasted memory. So before concluding "there's a memory problem," the first job is telling apart whether the cache is doing its job properly, or whether something is actually growing out of control.

✓ Probably fine

Usage is high, but the growth curve has leveled off and stayed there for a long time
Most of the high usage sits in the cache, and the cache hit rate stays healthy
The system still has available memory overall, with no swap activity

✕ Worth investigating

Usage keeps climbing with no plateau, all the way up to an OOM kill
The cache hit rate is dropping at the same time — a sign the working set no longer fits
The system starts swapping, or other processes are visibly starved for memory

02 · Where to Look

Don't guess — just ask the database directly

MongoDB can answer "where did the memory go" on its own, no extra tooling required.

① Actual resident memory vs. virtual memory

db.serverStatus().mem

② WiredTiger cache usage, configured limit, and eviction activity

db.serverStatus().wiredTiger.cache

Three fields matter most: bytes currently in the cache (current usage), maximum bytes configured (the configured ceiling), and pages evicted by application threads (evictions forced directly by app threads — a sudden jump here usually means the working set no longer fits in cache).

③ Current connection count — every connection carries a fixed memory overhead

db.serverStatus().connections

03 · Common Causes

Memory trouble usually comes down to one of these

WiredTiger Cache Sized Too Large

It crowds out the OS's own filesystem cache — especially easy to miss in containerized / cgroup-limited environments, where MongoDB may still size its cache off the host's total memory instead of what the container actually has available.

Too Many Connections

Every connection carries a fixed memory overhead. A poorly sized connection pool, or clients that disconnect abnormally without releasing their connection, multiplies that cost quickly.

Sorts & Aggregations Not Using an Index

An in-memory sort over 32MB gets rejected unless disk spill is explicitly allowed; aggregation stages like $group and $lookup can also accumulate large intermediate results in memory.

Oversized Documents or Ever-Growing Arrays

A single document that's too large, or one with an array field that keeps getting appended to, can inflate the working set far beyond what you'd expect.

WAP Note

Cache hit rate, memory usage, connection count — these are all metrics WAP tracks continuously. Rather than digging through logs after an OOM kill, it's better to catch these curves climbing abnormally before it happens.

04 · Fixes

Once you've found the cause, here's what to do

WiredTiger cache is consuming nearly all available memory→Resize wiredTigerCacheSizeGB based on what's actually available to the container/host, leaving room for the OS

Connection count stays persistently high→Review connection pool settings and check for clients that aren't closing connections properly

Sorts / aggregations frequently exceed the memory limit→Add the missing index for the sort field, and enable allowDiskUse on the pipeline where needed

A collection has abnormally bloated documents→Restructure the document model — avoid embedding unbounded arrays in a single document

One Last Thing

The scariest part of a memory issue
is finding out too late

Looking back at most memory incidents, there's almost always a clean, climbing curve you could have seen coming — nobody was just watching it at the time. Continuously tracking these metrics is something Whaleal Platform does every single day.

Learn About WAP → Read the Docs