MongoDB on Netdata

Best MongoDB Monitoring Tools (10 Ranked for 2026)

Wed, 12 Aug 2026 00:00:00 +0000

Database Performance Monitoring: 14+ DBs Supported

Fri, 24 Apr 2026 00:00:00 +0000

Netdata has always collected database metrics: connections, throughput, replication lag, buffer cache hit ratios, and so on. These tell you that something is wrong, but they don’t tell you why. When your PostgreSQL response time spikes, the metric alone doesn’t tell you which query is responsible. For that, you’ve traditionally needed to SSH into the box, connect to the database, and run diagnostic queries manually. Or set up a separate database monitoring tool entirely.

Database Monitoring Software Without Query Languages

Tue, 27 Jan 2026 00:00:00 +0000

Netdata gives DBAs complete database visibility with per-second query performance, replication lag tracking, lock analysis, and connection pool monitoring across MySQL, PostgreSQL, SQL Server, Oracle, and MongoDB - all from one dashboard with zero configuration.

Database Monitoring Software With Real-Time Visibility

Thu, 18 Dec 2025 00:00:00 +0000

Real-time database monitoring with AI-powered troubleshooting, zero configuration, and predictable costs. Monitor 15+ database platforms with per-second granularity and ML-based anomaly detection.

How to Troubleshoot Slow Queries in MongoDB

Mon, 27 May 2024 00:00:00 +0000

MongoDB is a popular NoSQL database known for its flexibility and scalability. However, as with any database system, you might encounter slow queries that can impact the performance of your application. In this guide, we’ll walk you through the steps to troubleshoot and optimize slow queries in MongoDB, ensuring your database runs efficiently.

Understanding the Basics

Before diving into troubleshooting, it’s important to understand some basic concepts in MongoDB:

Collections and Documents: MongoDB stores data in collections, which are analogous to tables in relational databases. Each collection contains documents, which are JSON-like data structures.
Indexes: Indexes improve query performance by allowing the database to quickly locate the data without scanning every document.
Query Plans: MongoDB evaluates different ways to execute a query and chooses the most efficient plan.

Identifying Slow Queries

Using the slowms Parameter MongoDB logs operations that take longer than a specified threshold. By default, this threshold (slowms) is set to 100 milliseconds. You can adjust this setting to catch slower operations more effectively:

Release 1.21: New Collectors & Faster Exporters

Mon, 06 Apr 2020 00:00:00 +0000

We’re in the middle of a scary, uncertain time, and we hope those of you reading are staying safe and healthy.

Despite the current challenges, the 40+ members of the remote-first Netdata team have been hard at work on the next version of the Netdata Agent: v1.21.0.

This release is foundational: While we do have fantastic new collectors and three new ways to export your metrics for long-term storage, many of the most significant changes aren’t even those you’ll notice. While they may be beneath the hood, they’re going to power some amazing new features, UX improvements, and design overhauls.

Release 1.17: Collection frequency gets flexible

Mon, 09 Sep 2019 00:00:00 +0000

The next version of Netdata has arrived! Aside from dozens of quality-of-life and papercut fixes, we’ve launched some new features we know you’ll be excited to use straight away.

Let’s dive in.

What’s new?

Release v1.17.0 contains 38 bug fixes, 33 improvements, and 20 documentation updates.

You can, of course, view the full list at the v1.17.0 release notes on GitHub. But, let’s talk details on a few of the improvements and changes most requested by the Netdata community.

MongoDB Application Thread Evictions: How To Fix

Mon, 01 Jan 0001 00:00:00 +0000

Query p99 latency doubles or triples, but iostat is not saturated and the slow query log shows no single offender. The signal is in db.serverStatus().wiredTiger.cache: pages evicted by application threads has moved from zero to a sustained nonzero rate.

This metric marks the moment when WiredTiger’s dedicated eviction workers fall behind and application threads are drafted to do the work. Any sustained nonzero rate is abnormal. Once application threads evict, they perform page reconciliation and disk I/O inline with the request handler thread, directly inflating user-visible latency. The companion counter pages selected for eviction unable to be evicted means eviction is stalled and the cache is effectively frozen.

MongoDB Balancer Stuck On Jumbo Chunks: Fix It

Mon, 01 Jan 0001 00:00:00 +0000

One shard is hot while the others idle. sh.status() shows chunk counts skewed more than 20%. The balancer is either stopped or running without closing the gap. Until you fix the root cause, the imbalance persists.

Two failure modes cause this. The balancer itself can be disabled, restricted to a narrow window, or blocked by an unhealthy config server. Or the cluster has jumbo chunks: ranges that exceed the configured chunkSize but cannot split because too many documents share the exact same shard key value. MongoDB marks those chunks jumbo in config.chunks and the balancer skips them. That heavy chunk pins load and storage on a single shard and creates a floor on how balanced the cluster can become.

MongoDB cache too small: sizing the WiredTiger cache for your working set

Mon, 01 Jan 0001 00:00:00 +0000

When MongoDB latency doubles and disk read IOPS climb, operators usually check indexes and the query planner first. If db.currentOp() shows no runaway query and the slow query log is quiet, the culprit is often the WiredTiger cache.

WiredTiger maintains its own in-memory cache of uncompressed B-tree pages, separate from the OS page cache. MongoDB defaults the cache to max(0.5 * (RAM - 1 GB), 256 MB). That default works for a single mongod on a dedicated host, but it breaks down in containers, multi-tenant deployments, and during organic data growth. Once the working set exceeds the cache, reads fault to disk, pages are decompressed, and eviction threads compete with application threads for CPU.

MongoDB checkpoint duration climbing: diagnosing slow WiredTiger checkpoints

Mon, 01 Jan 0001 00:00:00 +0000

You notice transaction checkpoint most recent time (msecs) climbing past 10 seconds, then 30, then 50. It is trending upward, check after check, approaching the 60-second default checkpoint interval. When checkpoint duration meets or exceeds the interval, WiredTiger has no margin left. The next checkpoint starts late, dirty pages accumulate faster than they flush, and the journal can fill to the point where all new writes block until the checkpoint finishes. This is a common production failure mode that starts as a slow climb and ends as a write freeze.

MongoDB checkpoint stall write freeze: when all writes stop with no error

Mon, 01 Jan 0001 00:00:00 +0000

Writes time out or hang while mongod is running, TCP port 27017 is open, and reads still return results from cache. The MongoDB logs are quiet, but db.serverStatus().opcounters shows write counts frozen. This is a WiredTiger checkpoint stall: the checkpoint process fell behind, dirty pages accumulated, and new writes blocked. The freeze lasts until the current checkpoint completes. If the I/O bottleneck remains, queued writes flood through and the next checkpoint stalls again.

MongoDB connection churn: high totalCreated rate and thread creation overhead

Mon, 01 Jan 0001 00:00:00 +0000

db.serverStatus().connections can show low current and a rapidly climbing totalCreated. That mismatch is connection churn: connections open and close rapidly instead of being reused. MongoDB allocates server-side state for every new connection; in thread-per-connection deployments, each cycle costs roughly a megabyte of thread stack, scheduling overhead, and file descriptor work. The result is rising RSS, CPU contention, and latency spikes that do not correlate with the active connection count.

For the broader mental model, see How MongoDB actually works in production: a mental model for operators. For the cascade after a failover, see MongoDB connection storm spiral: reconnection floods after an election or deploy.

MongoDB connection refused at maxIncomingConnections: hitting the connection ceiling

Mon, 01 Jan 0001 00:00:00 +0000

Application logs show connection timeouts. MongoDB logs show connection refused or error accepting new connection. db.serverStatus().connections shows current well below the configured maximum. This disconnect means you are hitting a hard ceiling at the TCP accept layer, not experiencing gradual degradation.

MongoDB uses a one-thread-per-connection model. Each accepted connection consumes two file descriptors and a thread stack sized by the OS ulimit -s. While maxIncomingConnections sets the logical inbound cap, the OS file-descriptor limit (ulimit -n) usually enforces the actual ceiling. Rejections happen before the connection handshake completes, so serverStatus().connections.current never counts refused connections. Look at logs, ratios, and OS-level resource counts to find the real limit.

MongoDB connection storm spiral: reconnection floods after an election or deploy

Mon, 01 Jan 0001 00:00:00 +0000

Connection count on a primary jumps from 200 to 4,000 in under a minute. Resident memory climbs, query latencies double, and application logs fill with timeout errors. The slow query log shows nothing unusual. Individual queries are not the problem. The database is drowning in threads.

This is a connection storm spiral. A trigger event, usually a replica set election, application deploy, or network blip, invalidates existing connections across your application fleet. Every driver reconnects at once. Each new connection costs MongoDB a dedicated thread and roughly 1 MB of stack memory. The resulting RSS spike and ticket contention slow down operations already in flight, causing more timeouts, which drives even more reconnections. The feedback loop ends in OOM kill or unresponsiveness.

MongoDB disk full: emergency recovery when mongod can't write the journal

Mon, 01 Jan 0001 00:00:00 +0000

When the filesystem backing the data or journal directory crosses a critical threshold, WiredTiger cannot allocate new journal extents. If mongod crashes or restarts, recovery replays journal files since the last checkpoint and requires free headroom to create or extend files during that replay. On a full disk, mongod hangs in recovery without binding to port 27017.

If the node is a standalone, there is no replica to fail over to. If it is a secondary, cluster redundancy is reduced while the member is down. Recovery is complicated by a counterintuitive storage engine behavior: WiredTiger reclaims space internally after deletes, but does not automatically shrink data files or return bytes to the operating system. A volume that reads 99% full after a massive delete remains 99% full at the filesystem level.

MongoDB disk I/O saturation: correlating iostat with WiredTiger signals

Mon, 01 Jan 0001 00:00:00 +0000

When opLatencies.writes climbs and globalLock.currentQueue grows, db.serverStatus().wiredTiger.transaction often shows the most recent checkpoint took 45 seconds. WiredTiger metrics tell you what is hurting, but they do not tell you why. The next question is whether the disk is actually saturated.

Disk I/O saturation surfaces as climbing journal sync latency, checkpoint duration exceeding the 60-second interval, application-thread evictions, and ticket exhaustion. The only way to separate a storage problem from a query problem is to correlate OS-level disk signals (iostat -x) with WiredTiger internal signals in the same time window. This guide shows how to do that safely during an incident.

MongoDB exceeded memory limit for $group — aggregation spills and allowDiskUse

Mon, 01 Jan 0001 00:00:00 +0000

Application logs show code 292 (QueryExceededMemoryLimitNoDiskUseAllowed), or an aggregation pipeline slows by an order of magnitude. Eligible blocking aggregation stages are limited to 100 megabytes of RAM. When a stage exceeds this limit and disk spilling is not enabled, the operation fails immediately. If spilling is enabled, MongoDB writes temporary files to disk, which keeps the pipeline alive but adds unpredictable latency and extra I/O load.

Before MongoDB 6.0, you had to explicitly opt in to disk spilling with { allowDiskUse: true }. Starting in 6.0, the allowDiskUseByDefault server parameter is true, so eligible stages spill automatically. That removes the hard failure for many pipelines, but it also makes it easier for heavy workloads to hide behind disk I/O instead of failing fast. The $push and $addToSet accumulators inside $group cannot spill to disk regardless of the setting. $graphLookup can spill when allowed by allowDiskUse; it returns an error only when spilling is prohibited.

MongoDB exposed to the internet without authentication: bindIp and the breach scenario

Mon, 01 Jan 0001 00:00:00 +0000

A mongod process bound to all interfaces with authentication disabled exposes every database to any host that can reach port 27017. If you are responding to a scan, PAGE, or audit, confirm the exposure, measure the blast radius, and eliminate the surface.

What this means

MongoDB’s net.bindIp controls which interfaces accept connections. Modern packages default bindIp to 127.0.0.1; exposure usually follows an explicit override to a wildcard such as 0.0.0.0 or ::. Without authentication, any reachable host can list databases, read or write documents, and execute administrative commands.

MongoDB journal sync latency high: the storage signal that warns 60 seconds early

Mon, 01 Jan 0001 00:00:00 +0000

Application write latency spikes. Connections pile up. Look back 60 seconds and WiredTiger journal sync latency was likely already climbing. Every write with j:true or w:"majority" blocks until the journal buffer is fsynced to disk. When storage struggles, journal sync is the first domino to fall.

Journal sync latency is a storage subsystem signal, not a query or cache problem. The block device under mongod cannot absorb small sequential writes fast enough. The result is head-of-line delay for all durable writes, which cascades into ticket exhaustion and connection backlog.

MongoDB lock wait times: collection and metadata lock contention during DDL

Mon, 01 Jan 0001 00:00:00 +0000

When p99 latency jumps and globalLock.currentQueue grows, check serverStatus().locks. If timeAcquiringMicros is climbing for Collection or Metadata, the cause is almost always DDL: createIndexes, dropIndexes, collMod, renameCollection, or similar commands that acquire exclusive collection, database, or metadata locks. WiredTiger uses document-level concurrency for ordinary reads and writes, so normal CRUD rarely blocks. A single schema change can serialize operations on a hot collection or across a database during peak traffic.

MongoDB long-running operations: finding and killing the query holding a ticket

Mon, 01 Jan 0001 00:00:00 +0000

Your application latency just spiked. opLatencies show reads and writes climbing. globalLock.currentQueue is no longer zero. You check db.serverStatus().wiredTiger.concurrentTransactions: available tickets are near zero, but throughput has not increased. An operation is holding a ticket without making progress.

A collection scan, an unbounded aggregation, or a stalled write can hold a WiredTiger read or write ticket for minutes. The default is 128 read and 128 write tickets in MongoDB ≤6.x (7.0+ dynamically adjusts, capped at 128), so one long-running operation can cascade into system-wide queuing, connection pileup, and application timeouts. Find it and kill it, but killing the wrong operation can crash a node or leave data inconsistent.

MongoDB Monitoring

Mon, 01 Jan 0001 00:00:00 +0000

MongoDB Monitoring

What Is MongoDB?

MongoDB is a leading NoSQL database platform designed for flexibility, scalability, and performance. It is used to store documents in a flexible, JSON-like format, which makes it perfect for handling large volumes of unstructured data. For more insights, check out MongoDB’s official site.

Monitoring MongoDB With Netdata

Netdata provides comprehensive monitoring for MongoDB, allowing users to gain real-time insights into their MongoDB servers. By utilizing the MongoDB monitoring tool from Netdata, users can track critical metrics and enhance their troubleshooting capabilities.

MongoDB monitoring checklist: the signals every production cluster needs

Mon, 01 Jan 0001 00:00:00 +0000

Production MongoDB failures are preceded by signals that are visible but often unmonitored: climbing dirty cache ratio, shrinking oplog window, or ticket counts approaching zero. This guide organizes essential signals into four monitoring levels. Use them to audit instrumentation or triage gaps during an incident.

Each level builds on the previous one. If you are missing a survival signal, instrument it before adding expert metrics. The thresholds below are drawn from the MongoDB serverStatus() and rs.status() contract and from operational patterns observed across WiredTiger deployments.

MongoDB no primary / election storm: repeated elections and write outages

Mon, 01 Jan 0001 00:00:00 +0000

Applications log “not primary” errors. rs.status() shows a different PRIMARY than thirty seconds ago. MongoDB logs repeat "Starting an election" and "Stepping down". Each election costs 2-12 seconds of write unavailability. More than two in ten minutes is an election storm.

This pattern is more dangerous than a single failover because it creates rolling write outages that do not self-stabilize. Drivers reconnect, retry buffers fill, and application latency degrades even when a primary exists. Root causes usually fall into three categories: the primary is too slow to answer heartbeats, the network is dropping or delaying packets between members, or a misconfigured priority is forcing a healthy primary to step down.

MongoDB not master error: writes hitting a non-primary node after failover

Mon, 01 Jan 0001 00:00:00 +0000

A node restart, network partition, or planned stepdown triggers a MongoDB election. Seconds later, application logs show NotWritablePrimary (code 10107) or the legacy string not master and slaveOk=false. Writes fail against a node that used to be PRIMARY, even though the cluster has elected a new one.

This guide covers how to find the root cause and stop it from recurring.

What this means

MongoDB replica sets elect exactly one PRIMARY at a time. When a failover occurs, the old primary steps down and a secondary is promoted. Application drivers discover the new topology through the replica set seed list and refresh their connection pools automatically. Between stepdown and election completion, there is a brief window with no writable primary. After the new primary is elected, drivers should route writes there.

MongoDB not primary and secondaryOk=false: reading from a secondary and how to fix it

Mon, 01 Jan 0001 00:00:00 +0000

Your application logs show NotPrimaryNoSecondaryOk (code 13435) with the message "not primary and secondaryOk=false" on hello-capable clients (or "not master and slaveOk=false" on legacy clients). Metrics show read failures against a specific host. The mongod process is running, replica set heartbeats are clean, and replication lag looks normal. The cluster is not down. The error is a routing decision: a client sent a read to a replica set member that is not the primary, without declaring that reading from a non-primary is acceptable.

MongoDB OOM-killed by the kernel: RSS, cache sizing, and oom_score_adj

Mon, 01 Jan 0001 00:00:00 +0000

You find mongod gone. The replica set has no primary. Applications time out. MongoDB logs show no graceful shutdown. Instead, dmesg shows Out of memory: Killed process 12345 (mongod). The Linux OOM killer has reaped the process. MongoDB is a frequent target because its resident set size is usually the largest on the host.

An OOM kill is not a MongoDB bug. It is the kernel freeing RAM by terminating the highest-scoring process. mongod’s RSS is dominated by the WiredTiger cache, plus roughly 1 MB per connection, plus roughly 500 MB to 1 GB of internal overhead for indexes, session buffers, and stack. When that sum comes within 1 GB of total RAM, the node is in the danger zone. The kill is abrupt: no stepdown, no replica set coordination, and after restart the cache must warm again.

MongoDB operation exceeded time limit (MaxTimeMSExpired): maxTimeMS and killed operations

Mon, 01 Jan 0001 00:00:00 +0000

Error code 50, MaxTimeMSExpired, means the server killed an operation that exceeded its processing budget. Raising the timeout without fixing the root cause turns acute failures into chronic resource exhaustion. The operation was already pathologically slow; maxTimeMS ended it before it consumed more resources or held locks and tickets indefinitely.

maxTimeMS sets a cumulative processing budget in milliseconds. MongoDB enforces it using the same interrupt mechanism as killOp, terminating the operation only at designated interrupt points. Idle time between cursor batches does not count toward the limit, and on direct connections network latency is excluded from the server-side clock. On sharded clusters, however, latency between mongos and shard mongod instances counts against the limit. Distinguish a true MaxTimeMSExpired from a client-side socket timeout, where the client gives up before the server responds.

MongoDB Operations Guides

Mon, 01 Jan 0001 00:00:00 +0000

How MongoDB actually fails in production, what the early warning signals look like, and the runbooks for the symptoms you’ll see in real incidents.

MongoDB oplog window collapse: secondaries falling off and forced full resync

Mon, 01 Jan 0001 00:00:00 +0000

A secondary transitions to RECOVERING and logs “too stale to catch up.” The oplog window compresses from 48 hours to 90 minutes while replication lag on one secondary climbs steadily. These are the signatures of oplog window collapse: a write surge turns over the oplog faster than secondaries can consume it, and the safety margin between window and lag evaporates.

Once a secondary falls behind the oldest entry in the primary’s oplog, its sync position no longer exists. Recovery requires a full initial sync, which can take hours to days depending on data size and network throughput. During recovery, the replica set runs with reduced redundancy. If another secondary is near the edge, the remaining members absorb increased read load that can push them toward the same fate.

MongoDB oplog window too small: sizing the oplog for your write volume

Mon, 01 Jan 0001 00:00:00 +0000

The oplog window is the only thing standing between a routine secondary restart and a multi-hour full initial sync. It is a fixed-size capped collection that stores a variable amount of history. As your write volume grows, the window compresses. Most teams size the oplog once during initial deployment and never look at it again. Six months later, a routine maintenance window turns into an incident because the secondary fell off the oplog, entered RECOVERING, and forced a resync that saturated the remaining nodes.

MongoDB page faults high: working set exceeding memory after warmup

Mon, 01 Jan 0001 00:00:00 +0000

A high page-fault rate long after startup can mean the active data set exceeds resident memory. extra_info.page_faults is platform-dependent; on Windows, MongoDB counts both hard and soft faults, so correlate the rate with OS-level disk-read/major-fault metrics. A brief spike after restart is normal during warmup, but sustained faults mean the working set does not fit. On EBS gp3, 50 faults per second can degrade latency. On NVMe, hundreds per second may be tolerable, but neither is free. Confirm the cause, distinguish warmup from pressure, and reduce the fault rate without guessing.

MongoDB rollback after failover: silent data loss and the rollback directory

Mon, 01 Jan 0001 00:00:00 +0000

A replica set member in ROLLBACK state, or an application reporting vanished documents after failover, means a former primary held writes that never reached a majority. When that node rejoins, MongoDB erases the divergent history and writes the removed data to files under <dbPath>/rollback/. The application may have received acknowledgment for those writes. With w:1, acknowledgment meant only that the primary applied the write. It did not guarantee replication to a majority or survival through failover. That is silent data loss.

MongoDB RSS growing without cache growth: leaks, threads, and tcmalloc fragmentation

Mon, 01 Jan 0001 00:00:00 +0000

db.serverStatus().mem.resident climbs while WiredTiger cache utilization stays flat and the host is not swapping. Virtual memory is larger than RSS by design and is not an alert target. Only RSS reflects physical memory pressure. When RSS grows without cache growth, the problem lives outside the storage engine.

This pattern points to one of three areas: tcmalloc heap retention and fragmentation, per-connection thread stack accumulation, or unbounded internal allocations from cursors, plan caches, or aggregation pipelines. Each connection reserves roughly 1 MB of stack space, so a connection storm can add gigabytes of RSS in minutes. TCMalloc caches freed memory in per-thread or per-CPU arenas, which inflates RSS independently of the WiredTiger cache.

MongoDB silent index regression: when a dropped index quietly becomes a collection scan

Mon, 01 Jan 0001 00:00:00 +0000

Read latency on the primary doubles while connection counts and write throughput stay flat. There are no election events or cache pressure alerts. Traffic is unchanged. Yet p99 read latency climbs until operations time out.

The slow query log shows queries that used to finish in milliseconds now taking seconds. The plans show COLLSCAN. An index that existed last week is gone, or the query planner switched to a less efficient index after a cache invalidation. Because queries still return correct results, the regression is silent until it becomes an outage.

MongoDB slow query COLLSCAN: collection scans and the missing index

Mon, 01 Jan 0001 00:00:00 +0000

Queries that used to return in tens of milliseconds now breach application timeouts. Read latency climbs while write throughput stays flat. In the MongoDB slow query log, you see planSummary: "COLLSCAN" attached to operations that should be indexed. A collection scan reads documents that will never be returned, wastes disk I/O, floods the WiredTiger cache with irrelevant data, and holds read tickets until the whole instance cascades into cache pressure.

MongoDB ticket exhaustion: WiredTiger read/write tickets and queued operations

Mon, 01 Jan 0001 00:00:00 +0000

Your application times out while the OS shows idle CPU and disk utilisation looks survivable. The MongoDB log shows no obvious errors, yet operations stall. The likely cause is WiredTiger ticket exhaustion: the storage engine has run out of read or write concurrency tokens, and new work queues behind slow operations. Confirm ticket starvation, find the root cause, and fix it without raising the ticket limit.

What this means

WiredTiger uses ticket-based admission control. Every operation that touches the storage engine must acquire a read or write ticket before it proceeds. In MongoDB 6.x and earlier, the default is 128 read and 128 write tickets per node. MongoDB 7.0 introduced a dynamic throughputProbing algorithm that adjusts the active ceiling downward from 128 under light load, scaling up under demand but never exceeding 128. In MongoDB 8.0+, the metrics moved from wiredTiger.concurrentTransactions to queues.execution, adding queue-length and timing fields that help distinguish true congestion from a low adaptive baseline.

MongoDB too stale to catch up: secondary stuck in RECOVERING and how to resync

Mon, 01 Jan 0001 00:00:00 +0000

You check rs.status() during an incident and see a member stuck in RECOVERING with a stale-oplog error. Older releases reported error RS102 too stale to catch up; newer releases log Too stale to catch up and return TooStaleToSyncFromSource internally. The node is alive but will never transition back to SECONDARY on its own. Its last replicated oplog entry is older than the oldest entry still available on the primary, so the history it needs has already been overwritten. Incremental replication is impossible from this state. The only path forward is a full initial sync, which on large datasets can take hours to days, adds significant read load to the sync source, and leaves the cluster with reduced redundancy until it completes. If the stale member is a voting node, you are now one failure away from losing majority. This guide covers how to confirm the condition, identify why the secondary fell off, and recover without pushing the remaining cluster members into the same trap.

MongoDB WiredTiger cache dirty ratio high: the leading indicator nobody watches

Mon, 01 Jan 0001 00:00:00 +0000

Cache fill at 70% looks safe, but if dirty ratio is climbing past 15%, a latency spike is already forming. Dirty ratio measures modified pages not yet flushed to disk. While fill ratio tells you how much cache is in use, dirty ratio tells you how fast the storage engine is falling behind. It often leads checkpoint stalls and eviction-driven latency spikes by minutes.

What this means

WiredTiger tracks dirty bytes against the configured maximum cache size. Dirty ratio equals tracked dirty bytes in the cache divided by maximum bytes configured. Checkpoints run every 60 seconds by default to flush these pages. When write volume exceeds flush capacity, dirty data accumulates.

MongoDB WiredTiger cache pressure cascade: eviction stalls and latency spikes

Mon, 01 Jan 0001 00:00:00 +0000

Latency jumps from milliseconds to seconds for both reads and writes. The slow query log shows no single offender, but connection count climbs as clients retry and timeout. This is the cache pressure cascade. It starts in the storage engine and becomes a self-reinforcing spiral through replication, admission control, and connection handling. This guide covers the mechanism, confirmation under pressure, and how to stop it.

What this means

WiredTiger uses an in-memory cache separate from the OS page cache. The default maximum is the larger of 50% of (RAM − 1 GB), or 256 MB. Writes land in cache as dirty pages; checkpoints flush them to disk every 60 seconds by default. Background eviction threads keep cache fill near 80% and dirty pages under control.

Webinar: Live Database & Network Diagnostics

Mon, 01 Jan 0001 00:00:00 +0000