Why this problem matters
Sustained cache pressure can increase query latency through more eviction and disk reads. High utilization alone is not proof of trouble because the cache is designed for use.
How to diagnose it
Compare byte and eviction counters in serverStatus().wiredTiger.cache over time. Correlate findings with working-set size, disk latency, and query volume.
WiredTiger counter names can expand across versions. Interpret changes over time rather than relying on one sample.
const c = db.serverStatus().wiredTiger.cache;
({bytesInCache: c["bytes currently in the cache"], maxBytes: c["maximum bytes configured"], pagesRead: c["pages read into cache"], pagesWritten: c["pages written from cache"]})A safe solution approach
Reduce inefficient queries, missing indexes, and unnecessarily large results first. Plan memory or data-placement changes only when working-set analysis supports them.
Why continuous monitoring matters
Continuous monitoring distinguishes normal cache occupancy from rising eviction pressure. moon tracks trends with low overhead and routes alerts to Slack, PagerDuty, or webhooks.
Frequently asked questions
Is high cache occupancy alone an alert condition?
Not by itself, because filling available cache is normal. Evaluate eviction, disk, and latency trends together.
How does moon help with this problem?
moon continuously observes SQL Server, PostgreSQL, and MongoDB signals, helping teams evaluate the problem as a trend instead of relying on a one-time check.