Why this problem matters
Rising page faults can indicate that the working set no longer fits memory or access patterns changed. Counter meaning varies by operating system and build, so it should not stand alone.
How to diagnose it
Track serverStatus().extra_info.page_faults over time when available. Cross-check operating-system major faults, disk latency, and WiredTiger cache metrics.
The page_faults field may not exist on every platform. Expand the cache object only when needed during interactive inspection.
const s = db.serverStatus();
({pageFaults: s.extra_info && s.extra_info.page_faults, cache: s.wiredTiger && s.wiredTiger.cache})A safe solution approach
Review query and index access patterns to reduce unnecessary disk reads. Consider capacity changes only when memory and I/O evidence indicate the same cause.
Why continuous monitoring matters
Continuous monitoring aligns counter increases with deployments or traffic changes. moon monitors MongoDB metrics with low overhead and routes Slack, PagerDuty, and webhook alerts.
Frequently asked questions
Does every page-fault increase indicate a disk problem?
No, some fault types are part of normal memory management. Operating-system metrics such as major faults and disk latency should confirm impact.
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.