MongoDB Lock Queue Growth: Diagnose Waiting Operations
Distinguishes lock waits from accompanying disk or memory pressure, identifies queued operations, and guides safe workload throttling.
Operational Safety & Risk Notice
This runbook contains operational intervention steps; several are write-impacting (KILL, terminate, DROP, RESIZE). Verify in a staging environment first, and apply sequentially in production with verification.
1. Symptom & Signals
`db.serverStatus().globalLock.currentQueue` büyüyor (M54); yazmalar ve bazen okumalar normalden yavaş. MongoDB'nin WiredTiger eşzamanlılık modelinde bu değer tek başına bloklayan tek bir oturum olduğu anlamına gelmez.
2. Business & Technical Impact
Gecikme ve zaman aşımları artar; yığılma bağlantı havuzunu ve bellek tüketimini yükseltebilir.
3. Diagnosis & Root-Cause Analysis
const s = db.serverStatus();
({ queue: s.globalLock.currentQueue, active: s.globalLock.activeClients,
locks: s.locks, writeConflicts: s.metrics?.operation?.writeConflicts });db.getSiblingDB('admin').aggregate([
{ $currentOp: { allUsers: true, idleConnections: false } },
{ $match: { waitingForLock: true } },
{ $project: { opid: 1, op: 1, ns: 1, secs_running: 1,
waitingForLock: 1, lockStats: 1, command: 1 } },
{ $sort: { secs_running: -1 } }
]);4. Remediation & Action Plan
5. Verification & Health Checks
M54 baz çizgiye dönüyor, `waitingForLock` azalıyor, uygulama p95/p99 gecikmeleri düşüyor ve yazma çakışma oranı artmıyor.
6. Rollback & Contingency Plan
Toplu iş hızını kontrollü eski düzeye çıkarın; kuyruğun yeniden büyümediğini doğrulayın. Kesilen işlemin etkisi geri alınmaz; uygulama idempotent şekilde tekrar denemeli.