MongoDB globalLock.currentQueue growing: operations queuing for the storage engine

globalLock.currentQueue.total is climbing and not stabilizing after a burst. Under WiredTiger, this metric reflects waits at the intent lock and ticket admission layers, not a single global mutex. The engine is receiving work faster than it can drain it.

If the total queue sustains above 20 and grows, the system is saturated. Queued operations become latency spikes, then connection pileups as applications retry, then a degradation spiral. The root cause is usually ticket exhaustion, a single hot collection, a long-running operation, or storage I/O degradation inflating ticket hold times.

What this means

db.serverStatus().globalLock.currentQueue returns { total, readers, writers }. Non-zero values mean operations are waiting. A small, stable queue under load is normal. A queue that grows without bound means the server cannot acquire the locks or tickets needed to execute work.

Under WiredTiger, globalLock reflects aggregate waits at the collection, document, and storage-engine ticket layers. When writers dominates and readers stays near zero, the bottleneck is typically a single write-heavy collection. When both grow together, the storage engine is saturated.

In MongoDB 7.0 and later, dynamic ticket adjustment changes how you interpret congestion. A low or zero available ticket count is expected behavior; the overload signal is a large, persistent queue of waiting operations. In MongoDB 8.0 and later, db.serverStatus().queues.execution provides the canonical admission-control view, including explicit queue-length and processing fields.

Common causes

Quick checks

# Check queue depth and composition
mongosh --quiet --eval 'db.serverStatus().globalLock.currentQueue'

# Check available tickets on MongoDB 6.x and earlier
mongosh --quiet --eval 'db.serverStatus().wiredTiger.concurrentTransactions'

# Check admission queue length on MongoDB 8.0+
mongosh --quiet --eval 'db.serverStatus().queues.execution'

# Find long-running operations
mongosh --quiet --eval 'db.currentOp({ "active": true, "secs_running": { "$gt": 10 } }).inprog.forEach(o => print(o.opid, o.op, o.secs_running, o.ns))'

# Find operations waiting for locks
mongosh --quiet --eval 'db.currentOp({ "waitingForLock": true }).inprog.forEach(o => print(o.opid, o.op, o.ns))'

# Check lock wait times by type
mongosh --quiet --eval 'var locks = db.serverStatus().locks; for (var type in locks) { var l = locks[type]; if (l.acquireWaitCount) { for (var mode in l.acquireWaitCount) { print(type, mode, "waits:", l.acquireWaitCount[mode], "us:", l.timeAcquiringMicros[mode]); } } }'

# Check checkpoint duration and raw journal sync counters
mongosh --quiet --eval 'var t=db.serverStatus().wiredTiger.transaction; print("checkpoint ms:", t["transaction checkpoint most recent time (msecs)"]); var l=db.serverStatus().wiredTiger.log; print("sync us:", l["log sync time duration (usecs)"], "ops:", l["log sync operations"])'

# Check cache dirty ratio
mongosh --quiet --eval 'var c=db.serverStatus().wiredTiger.cache; var max=c["maximum bytes configured"]; print("dirty %:", (100*c["tracked dirty bytes in the cache"]/max).toFixed(1))'

How to diagnose it

1. Confirm the queue is growing, not spiking. Sample globalLock.currentQueue at 10-second intervals. A burst to 50 that drops to 0 is normal. Sustained >20 over minutes is saturation.

2. Determine the composition. Writers-only suggests a collection hotspot or DDL. Mixed growth suggests systemic storage saturation.

3. Correlate with tickets (version-aware). On MongoDB 6.x and earlier, if wiredTiger.concurrentTransactions.write.available is near zero while the queue grows, tickets are exhausted. On MongoDB 7.0+, dynamic adjustment means available may be zero by design; focus on whether the queue persists. On MongoDB 8.0+, inspect queues.execution for explicit queue-length growth.

4. Inspect current operations. Use db.currentOp() to find operations running longer than 60 seconds or waiting for locks. Note the namespace and operation type. A single long-running aggregation or uncommitted transaction can pin resources and back up the queue.

5. Check storage health. Review WiredTiger checkpoint duration, journal sync latency, and cache dirty ratio. If the dirty ratio is above 10% and checkpoint duration is climbing toward 30 seconds, slow I/O is causing operations to hold tickets longer.

6. Review lock stats and slow queries. Growing timeAcquiringMicros under Collection or Metadata confirms lock contention. Slow query log entries with COLLSCAN or high keysExamined to docsReturned ratios reveal queries consuming tickets without making progress.

Metrics and signals to monitor

Fixes

Kill or throttle the offending operation

If db.currentOp() shows a runaway query, aggregation, or abandoned multi-document transaction, terminate it with db.killOp(opid) to release tickets and locks. Warning: killing a write operation may leave data partially updated if it is not idempotent. Aborting a transaction is safer but requires application retry logic.

Reduce write throughput

If a bulk import, migration, or batch job is driving the queue, pause or throttle it. This is often the fastest way to drain a saturated ticket pool and prevent cache pressure from compounding.

Address storage I/O degradation

If journal sync latency or checkpoint duration is elevated, inspect the underlying disk. On cloud VMs, burst-credit depletion is a common cause. If the primary is affected, stepping down to a secondary on healthier storage can restore throughput. Warning: stepping down triggers an election and brief write unavailability.

Reschedule DDL operations

If the queue correlates with an index build, collMod, or chunk migration, move the operation to a maintenance window. Foreground DDL holds locks that serialize production traffic.

Prevention

• Monitor globalLock.currentQueue as a trend. Alert on sustained growth rather than transient spikes.
• Track ticket utilization (or queues.execution on 8.0+) alongside queue depth to see admission pressure before it becomes latency.
• Keep the slow query log enabled and review it weekly. Collection scans and missing indexes are common precursors to queue events.
• Maintain storage headroom. Cloud disks with burst-credit models need usage buffers; on-prem disks need RAID health monitoring to avoid I/O degradation that inflates ticket hold times.

How Netdata helps

• Auto-collects globalLock.currentQueue, wiredTiger.concurrentTransactions, and queues.execution (8.0+).
• Correlates queue depth with cache dirty ratio, checkpoint duration, and journal sync latency.
• Surfaces long-running operations via db.currentOp() metrics.
• Per-second resolution catches trends that minute-level sampling misses.

Related guides

• How MongoDB actually works in production: a mental model for operators
• MongoDB pages evicted by application threads: when eviction becomes user latency
• MongoDB WiredTiger cache dirty ratio high: the leading indicator nobody watches
• MongoDB WiredTiger cache pressure cascade: eviction stalls and latency spikes
• MongoDB cache too small: sizing the WiredTiger cache for your working set
• MongoDB checkpoint duration climbing: diagnosing slow WiredTiger checkpoints
• MongoDB checkpoint stall write freeze: when all writes stop with no error
• MongoDB connection refused at maxIncomingConnections: hitting the connection ceiling
• MongoDB connection storm spiral: reconnection floods after an election or deploy
• MongoDB flow control throttling writes: when the primary slows itself down
• MongoDB journal sync latency high: the storage signal that warns 60 seconds early
• MongoDB monitoring checklist: the signals every production cluster needs